On 03/11/10 20:57, Alex Hunsaker wrote:
> On Wed, Nov 3, 2010 at 10:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> OK, applied.
>
> Thanks!
>
>> I notice that plpython is also using the trigger relation's OID, but I
>> don't know that language well enough to tell whether it really needs to.
>
> This thread was started by someone working a plpython a validator, I
> figured the two areas overlap somewhat and did not want to step on any
> toes. Anyhow the patch is tiny. So toes should remain intact. Find
> it attached.
Yeah, it just needs a flag to say trigger/not (but it does need a flag,
for the same reason plperl needs it).
By the way, I'm leaning in the direction of not using a Python
dictionary for the cache, but a standard Postgres HTAB instead. It's
more like other pls this way, and you can get rid of PyCObjects (which
are deprecated BTW) and messing around with reference counting the
cached procedures.
I was even thinking about having *two* hash tables, for trigger and
nontrigger procedures. This way you can make the function OID (which is
useful to hav anyway) be the first field of the structure being cached
and make both hash tables keyed by OIDs. Saves you the trouble of
defining a structure for the key... Not sure if it'll turn out for the
better, but I'm definitely for not using a Python dictionary for the cache.
The validator is ready, once I'm done with the hash tables I'll try to
fix up the error checking (get rid of the global error state) and
finally do what started it all, that is make plpythonu use
subtransactions for SPI and be able to do:
try: plpy.execute("insert into foo values(1)")
except plpy.UniqueViolation, e: plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
Cheers,
Jan