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 AANLkTik+yXynyH2=R+Dthu8ptNhRZ_Roh+u8cDrMXLed@mail.gmail.com
Whole thread Raw
In response to Re: why does plperl cache functions using just a bool for is_trigger  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: why does plperl cache functions using just a bool for is_trigger
List pgsql-hackers
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?


pgsql-hackers by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: psycopg and two phase commit
Next
From: Dimitri Fontaine
Date:
Subject: Re: ALTER OBJECT any_name SET SCHEMA name