Horton

Re: why does plperl cache functions using just a bool for is_trigger

Alex Hunsaker <badalex@gmail.com>

View thread
From: Alex Hunsaker <badalex@gmail.com>
To: Jan Urbański <wulczer@wulczer.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-03T21:06:23Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove unnecessary use of trigger flag to hash plperl functions

On Wed, Nov 3, 2010 at 14:43, Jan Urbański <wulczer@wulczer.org> wrote:
> 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.

Well if they are deprecated and there is an arguably cleaner way to do
it... might as well.

> I was even thinking about having *two* hash tables, for trigger and
> nontrigger procedures...<snip>... 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.

*shrug*

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

Ouuu <googly eyes>.

[ now that eval { }, thanks to Tim Bunce, works with plperl it should
be possible to do something similar there as well.  Just noting the
possibility... not volunteering :) ]