PGXS: REGRESS_OPTS=--load-language=plpgsql
in [PgSql]
|
Prev: testing cvs HEAD - HS/SR - PANIC: cannot make newWAL entries during recovery
Next: Thread safety and libxml2
From: Robert Haas on 19 Feb 2010 13:50 On Fri, Feb 19, 2010 at 1:44 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Did we have consensus on exactly what CREATE OR REPLACE LANGUAGE would > do? Particularly in cases where the existing definition doesn't match > pg_pltemplate? I am of the opinion that any CREATE OR REPLACE command that completes without error should result in exactly the same final state that would have resulted had the object not existed when the command was issued. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 19 Feb 2010 14:09 David Fetter <david(a)fetter.org> writes: > CREATE OR REPLACE LANGUAGE is an even bigger tar pit. > http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php The reason that patch got rejected was that it was implementing CREATE IF NOT EXISTS --- under a false name. The problem with that is summarized here: http://archives.postgresql.org/pgsql-patches/2008-03/msg00416.php It wouldn't be that hard to implement actual CREATE OR REPLACE if we decide that's the most useful solution here. The code would need to be prepared to use heap_update instead of heap_insert, and to get rid of old dependencies, but there is plenty of precedent for that. The sticking point for me is still whether or not it's really a good idea for pg_dump to be emitting CREATE OR REPLACE LANGUAGE. It does not do that for any other object type. On the other hand, we've already made languages a special case in pg_dump, since it emits the abbreviated form of CREATE LANGUAGE in most cases rather than trying to duplicate the existing object definition. Maybe there wouldn't be any bad results in practice. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 19 Feb 2010 14:15 Tom Lane <tgl(a)sss.pgh.pa.us> writes: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I am still of the opinion that changing this was a bad idea for >> exactly this reason. We could perhaps ameliorate this problem by >> implementing CREATE OR REPLACE for languages and emitting that >> instead; then the command in the dump would be a noop. > > Not really going to help for existing dumps (nor future dumps made > with pre-9.0 pg_dump versions). > > However, the case that is probably going to be the most pressing is > pg_upgrade, which last I heard insists on no errors during the restore > (and I think that's a good thing). That uses the new version's pg_dump > so a fix involving new syntax would cover it. Not sure how helpful I'll be there, but I can't help placing the extension's proposal again. If we had extensions here, plpgsql would be a core maintained extension, made available by CREATE EXTENSION in the database (which initdb would do in templates), then have the language installed by means of issuing an INSTALL EXTENSION command. Now, what would help would be to have that support and have CREATE LANGUAGE foo; be kept for compatibility only and issue INSTALL EXTENSION foo; instead. For those still with me, the choice to have plpgsql available by default would then boil down to have initdb do the CREATE EXTENSION in the template database, the database owner would still have to run the INSTALL EXTENSION. So now --load-language is INSTALL EXTENSION and just works as intended. And older dumps are doing CREATE LANGUAGE plpgsql; which is converted to INSTALL EXTENSION plpgsql;, which just works only because the extension is made available by default. So that if there's a CREATE LANGUAGE plpythonu, say, installing this extension will only succeed when INSTALL EXTENSION plpythonu; has been done either in the template1 database before creating the target database, or in the target database itself. So now we have "smart" success and failure modes falling from the proposed model. I'll dare not say "Hope This Helps" as I realize I failed to provide any code for implementing the extension management proposal. But got back to acceptable sleeping patterns and should be able to get back on the topic later this year, unless (please) beaten to it :) Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 19 Feb 2010 14:47 Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > Not sure how helpful I'll be there, but I can't help placing the > extension's proposal again. > If we had extensions here, plpgsql would be a core maintained extension, > made available by CREATE EXTENSION in the database (which initdb would > do in templates), then have the language installed by means of issuing > an INSTALL EXTENSION command. Well, that isn't really going to help us in terms of what to do for 9.0. But the possibility that something like this might happen in future is one thing that makes me hesitant about extending CREATE LANGUAGE right now --- the more bells and whistles we put on it, the harder it will be to have a clean upgrade to an EXTENSION facility. One thing that strikes me about your proposal is that INSTALL EXTENSION doesn't sound like a CREATE OR REPLACE operation. It sounds like a CREATE IF NOT EXISTS operation, because there simply is not a guarantee that what gets installed is exactly what the user expected --- in particular, for pg_dump, it isn't guaranteeing that the new version's extension is exactly like what was in the old database. And that's not a bad thing, in this context; it's more or less the Whole Point. However it still leaves us with the problem that CINE is underspecified. In particular, since we have already got the notion that languages have owners and ACLs, I'm unsure what the desired state is when pg_dump tries to set the owner and/or ACL for a pre-existing language. I know what is likely to happen if we just drop these concepts into the existing system: restoring a dump will take away ownership from whoever installed the language (extension) previously. That doesn't seem very good, especially if the ownership of any SQL objects contained in the extension doesn't change. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 19 Feb 2010 14:51
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > David Fetter <david(a)fetter.org> writes: >> CREATE OR REPLACE LANGUAGE is an even bigger tar pit. >> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php > > The reason that patch got rejected was that it was implementing > CREATE IF NOT EXISTS --- under a false name. The problem with > that is summarized here: > http://archives.postgresql.org/pgsql-patches/2008-03/msg00416.php > > It wouldn't be that hard to implement actual CREATE OR REPLACE > if we decide that's the most useful solution here. The code > would need to be prepared to use heap_update instead of heap_insert, > and to get rid of old dependencies, but there is plenty of precedent > for that. > > The sticking point for me is still whether or not it's really a good > idea for pg_dump to be emitting CREATE OR REPLACE LANGUAGE. It does not > do that for any other object type. On the other hand, we've already > made languages a special case in pg_dump, since it emits the abbreviated > form of CREATE LANGUAGE in most cases rather than trying to duplicate > the existing object definition. Maybe there wouldn't be any bad results > in practice. We have all sorts of crufty hacks in pg_dump and the backend to cope with restoration of older dumps. Compared to some of those, this is going to be cleaner than newfallen snow. IMHO, anyway. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |