Hm, thinking again, I guess Tom Lane is right
Surely the initialization code would have to be run anyway ... and if
the function does import a pile of modules, do you really want to cache
all that in its pg_proc entry? What happens if some of the modules get
updated later?
Besides,
Is there a TODO here?
---
Tom Lane wrote:
> PFC <[EMAIL PROTECTED]> writes:
> >> If it were really expensive to derive bytecode from source text
> >> then maybe it'd make sense to do what you're doing, but surely that's
> >>
PFC <[EMAIL PROTECTED]> writes:
>> If it were really expensive to derive bytecode from source text
>> then maybe it'd make sense to do what you're doing, but surely that's
>> not all that expensive. Everyone else manages to parse prosrc on the
>> fly and cache the result in memory; why isn't plpyt
On Sun, May 28, 2006 at 09:12:34PM -0400, Tom Lane wrote:
> But we're still avoiding the central issue: does it make sense to dump a
> probin clause at all for plpython functions? If it's a compiled form of
> prosrc then it probably doesn't belong in the dump.
That's why I initially thought pg_du
If it were really expensive to derive bytecode from source text
then maybe it'd make sense to do what you're doing, but surely that's
not all that expensive. Everyone else manages to parse prosrc on the
fly and cache the result in memory; why isn't plpython doing that?
It depends on the numb
James William Pye <[EMAIL PROTECTED]> writes:
> I guess there are two ways to go about it. Simply remove the
> assumption that probin is only relevant to C functions; perhaps
> allowing a hardwired exception for builtin languages where allowing
> probin to be set would be deemed unsightly (ie, the
On Fri, May 26, 2006 at 11:21:32PM -0400, Tom Lane wrote:
> James William Pye <[EMAIL PROTECTED]> writes:
> > So is this "fix your broken PL" or "pg_dump should only be doing that for C
> > language functions"?
>
> Offhand it seems to me that pg_dump is behaving reasonably: it's storing
> probin i
James William Pye <[EMAIL PROTECTED]> writes:
> In PL/Py, I had the bright idea of storing bytecode in the probin field of the
> function's pg_proc row. However, this idea has lately become rather dim as I
> have recently rediscovered(thanks Adrian) that this breaks dumps; pg_dump
> outputs
> a PL
Hi,
In PL/Py, I had the bright idea of storing bytecode in the probin field of the
function's pg_proc row. However, this idea has lately become rather dim as I
have recently rediscovered(thanks Adrian) that this breaks dumps; pg_dump
outputs
a PL/Py function as "CREATE FUNCTION x() RETURNS y LANG
