Re: [HACKERS] PGXS: REGRESS_OPTS=--load-language=plpgsql

[David Christensen]

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 <t...@sss.pgh.pa.us> wrote:

Robert Haas <robertmh...@gmail.com> writes:

On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian <br...@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

elsewhere by the time all the dust settles).

pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges

and (2) revert the original patch.  Do you want to do one of those
(which?) or do you have another idea?

IMO, the non-ugly kludges are (1) implement CREATE OR REPLACE LANGUAGE

not an option unless you want to break pg_migrator for 9.0.


think of, so why would pg_dump do it for languages by default?

For #2, if you mean the pg_dump.c plpgsql hack for pg_migrator, that is 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

Regards,

David
--
David Christensen
End Point Corporation
da...@endpoint.com

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?

skip-create-lang-dupe.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers