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: Hannu Krosing <hannu@2ndquadrant.com>
Cc: Jan Urbański <wulczer@wulczer.org>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-04T17:07:58Z
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 Thu, Nov 4, 2010 at 03:54, Hannu Krosing <hannu@2ndquadrant.com> wrote:
>> > try:
>> >     plpy.execute("insert into foo values(1)")
>> > except plpy.UniqueViolation, e:
>> >     plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)
>>
>> Are you sure that having each try/except use a subtransaction is the
>> right way to do it ?

I assumed the try was purely so you could 'catch' things.  And did not
mean run it in a subtransaction (without the try block it still runs
in one).

Personally, I was looking more at:

>> > except plpy.UniqueViolation, e:
>> >     plpy.notice("Ooops, you got yourself a SQLSTATE %d", e.sqlstate)

Which to me says if SPI has an error we get a nice error object back,
that also lets you do the normal exception catching dance (if thats
what you are in to...) and translates IMO better to how plpgsql works
("exception when unique_violation").

> Another objection
>
>> I'd like to make it more explicit and use
>>
>> with plpy.subtransaction():
>>     do your stuff

Sounds more like a savepoint?