Search Postgresql Archives

Re: Supported plpgsql BEFORE ... EACH ROW behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 02/23/2007 02:03:25 AM, Richard Huxton wrote:
Karl O. Pinc wrote:

I want to write a plpgsql function for use as a
BEFORE ... EACH ROW function.  I want to modify
other tables even when the function returns NULL
and therefore the table on which the BEFORE
trigger is defined is not updated.

I think it's fairly common, actually. Returning NULL is cancelling the update *of that row* rather than aborting the transaction, so all side-effects should always survive.

Thats good news.  Thanks for the reply.  But...

Otherwise you couldn't update 100 rows and just skip one or two by returning NULL from a before trigger.

But wanting side effects _when_ those one or two rows are skipped
is probably not so common.  I could imagine a implimentation
of Postgresql that does a SAVEPOINT before executing
a BEFORE ... EACH ROW trigger and then decides whether or
not to ROLLBACK TO SAVEPOINT or RELEASE SAVEPOINT.
That would not break the usage case you give, but would
break what I want to do.  So this is what I'm wanting
assurance about.  I suppose this is kind of silly, seeing
as how it's a BEFORE trigger we're talking about the
db would not have been updated so a SAVEPOINT would
not really be appropriate.  But I did say I was
being paranoid.

Thanks again for the help.

Karl <kop@xxxxxxxx>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux