Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Supported plpgsql BEFORE ... EACH ROW behavior
- From: Richard Huxton <dev(at)archonet(dot)com>
- To: "Karl O. Pinc" <kop(at)meme(dot)com>
- Cc: pgsql-general(at)postgresql(dot)org
- Subject: Re: Supported plpgsql BEFORE ... EACH ROW behavior
- Date: Fri, 23 Feb 2007 08:03:25 +0000
- Message-id: <45DE9FCD(dot)6030306(at)archonet(dot)com>
Karl O. Pinc wrote:
Hi, 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.
Sorry for being paranoid about this but I want to double check before relying on behavior that few people probably use.
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.
Otherwise you couldn't update 100 rows and just skip one or two by returning NULL from a before trigger.
-- Richard Huxton Archonet Ltd
- Follow-Ups:
- Re: Supported plpgsql BEFORE ... EACH ROW behavior
- From: Karl O. Pinc
- Re: Supported plpgsql BEFORE ... EACH ROW behavior
- References:
- Supported plpgsql BEFORE ... EACH ROW behavior
- From: Karl O. Pinc
- Supported plpgsql BEFORE ... EACH ROW behavior
- Prev by Date: Re: Warning "TupleDesc reference leak"
- Next by Date: Re: Large Objects
- Previous by thread: Supported plpgsql BEFORE ... EACH ROW behavior
- Next by thread: Re: Supported plpgsql BEFORE ... EACH ROW behavior
- Indexes: