Re: [GENERAL] PlPython - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] PlPython
Date
Msg-id 13359.1056402798@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] PlPython  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [GENERAL] PlPython  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The behavior that I think would be most useful would be to automatically
>> transpose CREATE FUNCTION ... LANGUAGE "plpython" into CREATE FUNCTION
>> ... LANGUAGE "plpythonu".  Which we could do with an ugly hack in CREATE
>> FUNCTION (ugly, but no worse than things we've done to index opclass
>> names, for example).  But it could be too confusing.

> You mean in gram.y?  Yes, I think that is our only choice.

Actually I think it should be in functioncmds.c.  I moved the special
kluges for opclass names out of gram.y and into indexcmds.c awhile ago.
But that's just an implementation detail --- we really need to still be
thinking about whether this is the behavior we want or not.  Someone
else made a fair point that such a kluge might not actually make life
any easier for reloading dump files.  If we do it that way, then if a
non-superuser tries to CREATE FUNCTION ... LANGUAGE "plpython" it will
fail (not being trusted) and so he's got no hope of loading the dump
without editing anyway.  If that's true, there's not much point in
introducing a hidden kluge.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] PlPython
Next
From: Josh Berkus
Date:
Subject: Re: Two Phase Commit WAS: Re: Two weeks to feature freeze