Re: multiple CREATE FUNCTION AS items for PLs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)krosing(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multiple CREATE FUNCTION AS items for PLs
Date: 2012-12-28 15:32:43
Message-ID: 9411.1356708763@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
>> An alternative that has some amount of precedent in the Python world
>> would be to use comment pragmas, like this: ...
>> This way we could get this done fairly easily without any new
>> infrastructure outside the language handler.

+1 for not cluttering the generic CREATE FUNCTION syntax for this.
I note the parallel to plpgsql's #option syntax, too.

Hannu Krosing <hannu(at)krosing(dot)net> writes:
> To make this fast also for old-style functions, we should store compiled
> bytecode (.pyc) in
> database as well, perhaps putting it in pg_proc.probin as a base64
> encoded string (probin
> is not used fro non-C functions) or adding a new bytea column
> pg_proc.procode especially for this.

That might or might not be worth doing. In the absence of evidence that
plpython byte-compiling represents significant overhead for normal use,
it sounds a lot like premature optimization to me. In any case, it
should certainly not be done as part of the same patch Peter is thinking
about.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2012-12-28 15:53:21 Behaviour of bgworker with SIGHUP
Previous Message Tom Lane 2012-12-28 15:25:38 Re: SPI API and exceptions