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 21 Feb 2010 17:11 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> It will be owned by the bootstrap superuser, so the case is exactly >> the one that a non-superuser DBA would be faced with. > Or even a superuser other than the bootstrap superuser, no? I dump > out the DB on my 8.4 server and try to reload on 9.0 with --single and > it fails because, even though I'm a superuser, I can't replace a > language owned by someone else? No, superusers always pass all permissions checks. 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: Tom Lane on 21 Feb 2010 17:16 Bruce Momjian <bruce(a)momjian.us> writes: > Tom Lane wrote: >> Attached is a draft patch (no doc changes) that implements CREATE OR >> REPLACE LANGUAGE > How is pg_migrator affected by this? It always loads the the dump as > the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE? pg_dump would issue "CREATE OR REPLACE LANGUAGE plpgsql" which would succeed just fine, since it'd be issued by a superuser. I think the potential downsides of that are significantly smaller than having a special case that excludes plpgsql altogether --- for one example, it would still succeed in a custom installation that had been changed so that plpgsql wasn't installed by default. BTW, another problem I just noticed with the current kluge is that it fails to transfer any nondefault permissions that might have been attached to plpgsql. 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 21 Feb 2010 19:23 Tom Lane wrote: > Bruce Momjian <bruce(a)momjian.us> writes: > > Tom Lane wrote: > >> Attached is a draft patch (no doc changes) that implements CREATE OR > >> REPLACE LANGUAGE > > > How is pg_migrator affected by this? It always loads the the dump as > > the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE? > > pg_dump would issue "CREATE OR REPLACE LANGUAGE plpgsql" which would > succeed just fine, since it'd be issued by a superuser. > > I think the potential downsides of that are significantly smaller than > having a special case that excludes plpgsql altogether --- for one > example, it would still succeed in a custom installation that had been > changed so that plpgsql wasn't installed by default. Are we doing this just for plpgsql in pg_dump? > BTW, another problem I just noticed with the current kluge is that it > fails to transfer any nondefault permissions that might have been > attached to plpgsql. Well, I assumed the permissions would still come, just not the CREATE LANGUAGE, but now that I think about it you might be right. -- 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: David Fetter on 21 Feb 2010 21:06
On Thu, Feb 18, 2010 at 01:51:08PM -0800, David Fetter wrote: > Folks, > > While hacking on PL/Parrot, I ran across an issue where when trying > to load PL/pgsql, it's done unconditionally and fails. How do we > fix pg_regress to be a little more subtle about this? For now, and for the archives, I've come up with this ugly hack: REGRESS_OPTS = --dbname=$(PL_TESTDB) NEEDS_PLPGSQL = $(shell psql -Atc "SELECT setting::int < 90000 FROM pg_catalog.pg_settings WHERE name='server_version_num'") ifeq ($(NEEDS_PLPGSQL), "t") REGRESS_OPTS += $(if $PG_VERSION < 90000," --load-language=plpgsql", "") endif That works all the way back to 8.2, and to be honest, I'm not all that interested in making something that will work further back than that, especially for new projects. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |