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: David Christensen on 20 Feb 2010 18:42 On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas(a)gmail.com> writes: >>>> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian <bruce(a)momjian.us> >>>> wrote: >>>>> Well, I was asking why you labeled it "must fix" rather than >>>>> "should >>>>> fix". ?I am fine with the pg_regress.c change. >>> >>>> Yeah, if it makes life easier for other people, I say we go for it. >>> >>> I don't think that the way to fix this is to have an ugly kluge in >>> pg_dump and another ugly kluge in pg_regress (and no doubt ugly >>> kluges >>> elsewhere by the time all the dust settles). >> >> IMO, the non-ugly kludges are (1) implement CREATE OR REPLACE >> LANGUAGE >> and (2) revert the original patch. Do you want to do one of those >> (which?) or do you have another idea? > > For #2, if you mean the pg_dump.c plpgsql hack for pg_migrator, that > is > not an option unless you want to break pg_migrator for 9.0. > > If you implement #1, why would you have pg_dump issue CREATE OR > REPLACE > LANGUAGE? We don't do the "OR REPLACE" part for any other object I > can > think of, so why would pg_dump do it for languages by default? In what cases would one be able to meaningfully REPLACE a language, other than to not break when encountering an already installed language? i.e., in which cases would this not invalidate functions already written if you were changing from trusted to untrusted status or a different call handler, etc. If there is not a meaningful case for the OR REPLACE, and it is just a syntactic loophole to allow the errorless recreation of an existing language and if the parameters for the CREATE LANGUAGE call indicate identical final state, why aren't we free change change the semantics of CREATE LANGUAGE to just issue a NOTIFY instead of an error in that case, and only complain if there are differences in the call handler, trusted status, etc? I am including a preliminary patch to implement this behavior in the pg_pltemplate case; since we are already using the defaults from that entry and ignoring any explicitly provided ones in the command, this seems to be a safe assumption. Presumably you could do the same in the other case, if you verified that the existing pg_language tuple had the same relevant fields (i.e., notify without error). This would have the benefit of allowing CREATE LANGUAGE <langname> for those languages with pg_pltemplate entries (specifically plpgsql, but any with the same parameters) and would mean that we could use dumps from pre 9.0 in 9.0 without breaking, appears to fix --single, the pg_regress case, etc. Thoughts on the approach? Regards, David -- David Christensen End Point Corporation david(a)endpoint.com
From: "David E. Wheeler" on 20 Feb 2010 18:52 On Feb 20, 2010, at 15:03, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Well, I'm willing to implement CREATE OR REPLACE LANGUAGE if people > are agreed that that's a reasonable fix. I'm slightly worried about > the restore-could-change-ownership issue, but I think that's much less > likely to cause problems than embedding special cases for plpgsql in a > pile of places that we'll never find again. Just throwing this out there: would a syntax such as CREATE OF NOT EXISTS, a complement to DROP IF EXISTS, avoid the permissions issue? And if so, would that be a syntax we'd want to accept in general? Could the be a CREATE IF NOT EXISTS TABLE? Best, David -- 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 E. Wheeler" on 20 Feb 2010 18:55 On Feb 20, 2010, at 15:18, Andrew Dunstan <andrew(a)dunslane.net> wrote: > I also think we need to state explicitly that module authors can not > expect build files to be version ignorant and always work. Even if > we do something that handles this particular issue, that is likely > to be a happy coincidence rather than something that can be expected > all the time. People need to expect to have to do version-dependent > things. Sure, but where it cab easily be avoided it should be. Most Makefiles work as-is back to 8.0 and earlier AFAICT. Best, David -- 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 18:57 "David E. Wheeler" <david(a)kineticode.com> writes: > Just throwing this out there: would a syntax such as CREATE OF NOT > EXISTS, a complement to DROP IF EXISTS, avoid the permissions issue? No, it'd just move it to a different place: now you risk breaking the restored state rather than pre-existing state. > And if so, would that be a syntax we'd want to accept in general? > Could the be a CREATE IF NOT EXISTS TABLE? *Please* go read some of the linked older discussions before you propose that. I don't want to rehash it yet again. 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: "David E. Wheeler" on 20 Feb 2010 19:37
On Feb 20, 2010, at 3:57 PM, Tom Lane wrote: >> And if so, would that be a syntax we'd want to accept in general? >> Could the be a CREATE IF NOT EXISTS TABLE? > > *Please* go read some of the linked older discussions before you propose > that. I don't want to rehash it yet again. :-) Was just a thought. David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |