Subject: [HACKERS] psycopg2 license changed - msg#01129

Previous Message by Date:

Re: [HACKERS] Package namespace and Safe init cleanup for plperl [PATCH]

David E. Wheeler wrote: On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote: To perform initialisation, such as setting a value in %_SHARED. Hrm. Well, as a DBA, I'd *really* like to be able to make some things available from within a Safe container, such as Devel::NYTProf::PgPLPerl or the PostgreSQL::PLPerl::Call module that Tim's working on. Right now I can do that by hacking warnings.pm directly or by the method you figured out a few weeks ago, which isn't really all that nasty. I'm not sure that Tim's interface is the best approach to giving DBAs the ability to do this from within PostgreSQL, but I'm hard-pressed to come up with a better interface. But I do think it should be allowed. I am not saying we shouldn't. But that's a new feature, and we do have a process to follow. I think it's long past the time when we can accept new features which have had almost no discussion. And I am saying that any facility we provide for it has to be known and documented. Clearly there are modules which could probably be used with reasonable safety. Math::BigInt and MIME::Base64 are examples that come to mind as likely candidates. But I am not prepared to commit a patch providing this facility based on just having a variable declared using "use vars" rather than "my", without a word in the docs, and with almost no discussion on -hackers, and that discussion starting two weeks after the start of the final commitfest. That's just not the way we do things round here, AIUI. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Next Message by Date:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith <greg@xxxxxxxxxxxxxxx> wrote: > Robert Haas wrote: >> Recording some bookkeeping information in pg_class so that pg_migrator can >> tell what's going on >> at a glance seems like the right approach, but I'm fuzzy on the details. > > November of 2008 was a pretty good month for me, so I enjoyed this flashback > to it.  That's when the path for how to handle space reservation wandered to > this same place and then died there:  how to know for sure what information > to put into the catalog for the upgrade utility, before the upgrade utility > exists.  Message from Bruce at > http://archives.postgresql.org/message-id/200901300457.n0U4v1707979@xxxxxxxxxx > and my follow-up summarized/linked to the highlights of the earlier > discussion on that one. Sure. I think there's an a critical difference between the two discussions: the framework I'm proposing is general and applicable to almost any upgrade situation that changes the ODF in any way, and provides a general way of eventually desupporting ODFs we no longer want. The previous discussion was about a space reservation system which couldn't be made to work for a variety of reasons, including uncertainty about what the future needs might be, and lack of any sort of bookkeeping system (such as the one I'm proposing here) for tracking the current state of the system. > If you think through the implications of that far enough, eventually you > start to realize that you really can't even add a feature that requires an > in-place upgrade hack to fix without first having the code that performs > said hack done.  Otherwise you're never completely sure that you put the > right catalog pieces and related support code into the version you want to > upgrade from.  This is why it's not unheard of for commercial database > products to require a working in-place upgrade code *before* the feature > change gets committed. Agreed. > In this case, we get a lucky break in that it's easy to leave support for > old path in there and punt the problem for now.  I hope that we all learn > something useful about this class of issue during this opportunity to get > away with that with little downside. Yep. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Previous Message by Thread:

[HACKERS] "0 0" return tag

I have updated the attached C comment about why we return "0 0" for some tags. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/tcop/pquery.c =================================================================== RCS file: /cvsroot/pgsql/src/backend/tcop/pquery.c,v retrieving revision 1.134 diff -c -c -r1.134 pquery.c *** src/backend/tcop/pquery.c 2 Jan 2010 16:57:52 -0000 1.134 --- src/backend/tcop/pquery.c 13 Feb 2010 22:45:08 -0000 *************** *** 1318,1326 **** * If a command completion tag was supplied, use it. Otherwise use the * portal's commandTag as the default completion tag. * ! * Exception: clients will expect INSERT/UPDATE/DELETE tags to have ! * counts, so fake something up if necessary. (This could happen if the ! * original query was replaced by a DO INSTEAD rule.) */ if (completionTag && completionTag[0] == '\0') { --- 1318,1331 ---- * If a command completion tag was supplied, use it. Otherwise use the * portal's commandTag as the default completion tag. * ! * Exception: Clients expect INSERT/UPDATE/DELETE tags to have ! * counts, so fake them with zeros. This can happen with DO INSTEAD ! * rules if there is no replacement query of the same type as the ! * original. We print "0 0" here because technically there is no ! * query of the matching tag type, and printing a non-zero count for ! * a different query type seems wrong, e.g. an INSERT that does ! * an UPDATE instead should not print "0 1" if one row ! * was updated. See QueryRewrite(), step 3, for details. */ if (completionTag && completionTag[0] == '\0') { -- Sent via pgsql-hackers mailing list (pgsql-hackers@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Next Message by Thread:

Re: [HACKERS] psycopg2 license changed

On 2/13/10 5:13 PM, Federico Di Gregorio wrote: > Hi *, > > I just wanted all interested people know that psycopg2 2.0.14 to be > released in the next few days will be under the LGPL3 + OpenSSL > exception (example code and tests under the LGPL3 alone because they are > never linked to OpenSSL). Yaaay! Of course, now I'm on the hook to fix bugs. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers