Re: PGXS: REGRESS_OPTS=--load-language=plpgsql

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)endpoint(dot)com