Hannu Krosing <ha...@krosing.net> writes:
> On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ... OPTIONS (call_convention 'xyz')
> How about using a GUC for setting calling convention?
GUCs are a truly bad fit for properties that need to be function-local.
> This SET can be even done as part of CREATE FUNCTION .
> CREATE FUNCTION $$ ... $$ ... SET plpython.cc=9.2;
That doesn't fix the problem, because a setting made that way will
affect called functions too. The only way you could use it safely
would be to add such a SET clause to every single plpython function
in the database. At that point an OPTIONS clause (which can have a
backwards-compatible default behavior) looks a lot more attractive.
I still think that embedding some type of extension syntax in the
function body is the best solution. But if that's too ugly, let's
invent something like Peter's OPTIONS syntax above, with the
understanding that it affects only the function it's applied to
(unlike SET), and contains PL-specific options.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
