Re: [GENERAL] Using results from DELETE ... RETURNING

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Joshua Tolley <eggyknap(at)gmail(dot)com>, Shak <sshaikh(at)hotmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Using results from DELETE ... RETURNING
Date: 2009-06-13 08:33:59
Message-ID: 20090613083359.GI21830@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Sun, Jun 07, 2009 at 12:29:56AM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > Would it be super-complicated to do this with CTEs for 8.5? They
> > seem to have sane properties like getting executed exactly once.
>
> Hmm, interesting thought. The knock against doing RETURNING as an
> ordinary subquery is exactly that you can't disentangle it very well
> from the upper query (and thus, it's hard to figure out when to fire
> triggers, to take just one problem). But we've defined CTEs much
> more restrictively, so maybe the problems can be solved in that
> context.

I was discussing this with Andrew Gierth in IRC, who thought that
putting RETURNING inside the WITH clause would be relatively easy, at
least for the parser and planner. For the executor, he suggested that
one approach might be to make INSERT, UPDATE and DELETE into their own
nodes.

Comments?

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alban Hertroys 2009-06-13 10:45:12 Re: String Manipulation
Previous Message Frank Heikens 2009-06-13 08:05:35 Re: How to know the indexes on a Table

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2009-06-13 10:14:29 char() overhead on read-only workloads not so insignifcant as the docs claim it is...
Previous Message Dimitri Fontaine 2009-06-13 07:11:54 Re: Documentation: GiST extension implementation