Re: why does plperl cache functions using just a bool for is_trigger - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: why does plperl cache functions using just a bool for is_trigger
Date
Msg-id AANLkTinZe0W2E2G5zYozs--OgMSJJn3-tMQtFATQeeen@mail.gmail.com
Whole thread Raw
In response to Re: why does plperl cache functions using just a bool for is_trigger  (Jan Urbański <wulczer@wulczer.org>)
Responses Re: why does plperl cache functions using just a bool for is_trigger
List pgsql-hackers
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 :) ]


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: why does plperl cache functions using just a bool for is_trigger
Next
From: "David E. Wheeler"
Date:
Subject: Re: why does plperl cache functions using just a bool for is_trigger