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