Skip site navigation (1) Skip section navigation (2)

Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers
Date: 2006-10-12 19:00:13
Message-ID: 16078.1160679613@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
David Fetter <david(at)fetter(dot)org> writes:
> More generally, would this change impede promoting RETURNING to work
> just as VALUES does in 8.2 (i.e. being able to join RETURNING results,
> etc.)?

Making that happen would imply a whole lot of other changes; this issue
isn't the principal gating factor.  One of the main things I'd point to
right now, in view of this having all arisen from the question of when
triggers should fire, is where and when we'd fire BEFORE/AFTER STATEMENT
triggers for a RETURNING command embedded in a larger query.  For that
matter, the system has several not-easily-removed assumptions that a
SELECT command won't fire any triggers at all --- which would break down
if we allowed constructs like

	SELECT ... FROM (INSERT ... RETURNING ...) ...

We do currently have the ability to make plpgsql functions send
RETURNING results back to a calling query, and with this change we could
say the same of plain SQL functions --- and in both cases we'll be
depending on a tuplestore buffer to keep things sane in terms of when
triggers fire.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: David FetterDate: 2006-10-12 19:01:12
Subject: Re: create temp table .. on commit delete rows
Previous:From: Jim C. NasbyDate: 2006-10-12 19:00:12
Subject: Re: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group