Skip site navigation (1) Skip section navigation (2)

Re: pg_proc probin misuse

From: James William Pye <pgsql(at)jwp(dot)name>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_proc probin misuse
Date: 2006-05-29 07:00:57
Message-ID: 20060529070057.GB68377@lit.jwp.name (view raw or flat)
Thread:
Lists: pgsql-hackers
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_dump or I was the dirty one.
Even if CREATE FUNCTION would take it, the probin value would be ignored(well,
overwritten).

> On reflection I'm kind of inclined to think that plpython is abusing the
> column.  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?

Yeah, I don't think it's expensive. It wasn't a feature that I implemented
out of any kind of demand or testing. Rather, I knew I could marshal code
objects, and I figured it would likely yield some improvement on initial loads,
so I implemented it.

> If we think that plpython is leading the wave of the future, I'd be kind
> of inclined to invent a new pg_proc column in which derived text can be
> stored, rather than trying to use probin for the purpose.  Although
> arguably probin itself was once meant to do that, there's too much
> baggage now.

I think having something like that in pg_proc could be useful. Certainly my case
may not really be demanding, but I guess there may be some languages that could
enjoy a good benefit from avoiding recompilation. Tho, such a column seems like
it would be more of a mere convenience for PL authors. If initial load were
truly that expensive, I would think that it would justify creating a table
containing compiled code and taking the extra lookup hit on initial load.

In response to

pgsql-hackers by date

Next:From: Zeugswetter Andreas DCP SDDate: 2006-05-29 09:22:08
Subject: Re: Updatable views/with check option parsing
Previous:From: Martijn van OosterhoutDate: 2006-05-29 06:52:13
Subject: Re: LIKE, leading percent, bind parameters and indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group