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: Tom Lane on 19 Feb 2010 15:01 Robert Haas <robertmhaas(a)gmail.com> writes: > On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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. What worries me about it is mainly the prospect that restoring a dump would silently change ownership and/or permissions of a pre-existing language. Maybe we can live with that but it's a bit nervous making. One thing we could do that would help limit the damage is have pg_dump only insert OR REPLACE when it's emitting a parameterless CREATE LANGUAGE, ie, it's already depending on there to be a pg_pltemplate entry. This would guarantee that we aren't changing any of the core properties of the pg_language entry (since, because of the way CREATE LANGUAGE already works, any pre-existing entry must match the pg_pltemplate entry). But there's still ownership and ACL to worry about. 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 15:14 Tom Lane <tgl(a)sss.pgh.pa.us> writes: > 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. Agreed, but we could still evolve the command with keeping an eye on the future. As of now I intend to implement what's on this page: http://wiki.postgresql.org/wiki/ExtensionPackaging So maybe a quick glance then some early design approval would make it possible to change the CREATE LANGUAGE in an EXTENSION compatible way. > 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. In fact it's not either one or the other, because the CREATE EXTENSION is providing the meta data, which includes an optional upgrade function. So if you INSTALL EXTENSION over an existing one, and meantime you've been installing the new version (file system install, PGAN or distro packaged or source level install; then the new CREATE EXTENSION which should be given in the foo.sql for the foo EXTENSION), in this case it's an upgrade, and what INSTALL EXTENSION is meant to do is run the upgrade function with as arguments current and new version numbers. It's when the EXTENSION is not providing this upgrade function that the behavior is more CREATE OR REPLACE, because it'd then run the installation script all over again. In case you provided an upgrade function, we're yet to see how to provide facilities to the extensions authors in order to easily address the columns of their data type and the indexes from their operator classes, etc. 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: Bruce Momjian on 20 Feb 2010 12:45 Dimitri Fontaine wrote: > Tom Lane <tgl(a)sss.pgh.pa.us> writes: > > 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. > > Agreed, but we could still evolve the command with keeping an eye on the > future. As of now I intend to implement what's on this page: > > http://wiki.postgresql.org/wiki/ExtensionPackaging > > So maybe a quick glance then some early design approval would make it > possible to change the CREATE LANGUAGE in an EXTENSION compatible way. > > > 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. > > In fact it's not either one or the other, because the CREATE EXTENSION > is providing the meta data, which includes an optional upgrade > function. So if you INSTALL EXTENSION over an existing one, and meantime > you've been installing the new version (file system install, PGAN or > distro packaged or source level install; then the new CREATE EXTENSION > which should be given in the foo.sql for the foo EXTENSION), in this > case it's an upgrade, and what INSTALL EXTENSION is meant to do is run > the upgrade function with as arguments current and new version numbers. > > It's when the EXTENSION is not providing this upgrade function that the > behavior is more CREATE OR REPLACE, because it'd then run the > installation script all over again. > > In case you provided an upgrade function, we're yet to see how to > provide facilities to the extensions authors in order to easily address > the columns of their data type and the indexes from their operator > classes, etc. This discussion is sounding very design-ish, which makes me think we should just leave things unchanged for 9.0 and have external regression test designers work around this problem in their Makefiles, as Alvaro suggested. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- 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 20 Feb 2010 12:49 Bruce Momjian <bruce(a)momjian.us> writes: > This discussion is sounding very design-ish, which makes me think we > should just leave things unchanged for 9.0 and have external regression > test designers work around this problem in their Makefiles, as Alvaro > suggested. I would have said that some time ago, except that I think we have a "must fix" issue here: isn't pg_upgrade broken for any database containing plpgsql? A decent solution for that probably will allow something to fall out for the regression test problem too. 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: Bruce Momjian on 20 Feb 2010 12:57
Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > This discussion is sounding very design-ish, which makes me think we > > should just leave things unchanged for 9.0 and have external regression > > test designers work around this problem in their Makefiles, as Alvaro > > suggested. > > I would have said that some time ago, except that I think we have a > "must fix" issue here: isn't pg_upgrade broken for any database > containing plpgsql? A decent solution for that probably will allow > something to fall out for the regression test problem too. Uh, well, I added this to pg_dump.c for 9.0: else if (g_fout->remoteVersion >= 80300) { /* pg_language has a lanowner column */ /* pg_language has a lanowner column */ appendPQExpBuffer(query, "SELECT tableoid, oid, " "lanname, lanpltrusted, lanplcallfoid, " "lanvalidator, lanacl, " "(%s lanowner) AS lanowner " "FROM pg_language " "WHERE lanispl%s " "ORDER BY oid", username_subquery, binary_upgrade ? "\nAND lanname != 'plpgsql'" : ""); --------------------------------------------------- meaning it will not dump plpsql when doing a binary upgrade. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |