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
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 |