Re: why does plperl cache functions using just a bool for is_trigger
От | Alex Hunsaker |
---|---|
Тема | Re: why does plperl cache functions using just a bool for is_trigger |
Дата | |
Msg-id | AANLkTinZe0W2E2G5zYozs--OgMSJJn3-tMQtFATQeeen@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why does plperl cache functions using just a bool for is_trigger (Jan Urbański <wulczer@wulczer.org>) |
Ответы |
Re: why does plperl cache functions using just a bool for is_trigger
|
Список | 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 по дате отправления: