On Wed, Nov 5, 2008 at 11:20 AM, Rafal Pietrak <rafal@xxxxxxxxxxxxxxxxxx> wrote: > Hi, > > On Wed, 2008-11-05 at 10:34 -0500, Merlin Moncure wrote: >> On Wed, Nov 5, 2008 at 2:41 AM, Rafal Pietrak <rafal@xxxxxxxxxxxxxxxxxx> wrote: >> > Hi Everybody, > [...] >> > I've just upgraded to v8.3.4 ... since eventually it does have >> > INSERT ... RETURNING extention to the SQL standard. >> > >> > The documentation was quite encouraging: "if INSERT contains RETURNING, >> > the result is similar to SELECT....". > [....] >> This is a (very) faq. >> Everyone wants it. > > I see. Sounds promising :) > >> It's more complicated than it looks (triggers). > > Could you give me pointers where I could get some more information on > this problems? (simple postgres-doc-search and google queries on the > subject didn't gave any interesting results). see: http://markmail.org/message/yst7y3bjqbso7i33 Tom Lane wrote: "Making [returning work as select] 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." -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
