Re: GSOC13 proposal - extend RETURNING syntax

From: Karol Trzcionka <karlikt(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GSOC13 proposal - extend RETURNING syntax
Date: 2013-05-02 19:25:57
Message-ID: 5182BDC5.5030406@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

W dniu 02.05.2013 20:45, Tom Lane pisze:
> David Fetter <david(at)fetter(dot)org> writes:
>> Maybe we can make BEFORE and AFTER implied aliases rather than
>> keywords. What say?
> Well, they still have to be unreserved keywords for their use in
> trigger-related commands, but as far as this feature is concerned
> I think they're best off being handled as automatically-supplied
> aliases. IOW the patch needn't touch gram.y at all.
Well... the syntax which wouldn't conflict with Pl/PgSQL is (draft):
INSERT INTO foo ... RETURNING AFTER.*
UPDATE foo SET ... RETURNING AFTER.*, BEFORE.*
DELETE FROM foo ... RETURNING BEFORE.*
It will not solve the problems:
1. How to access to old rows if the table is named "BEFORE"?
2. Should AFTER for DELETE and BEFORE for INSERT be allowed? If yes what
should they return? I mean: what should be result of:
INSERT INTO foo ... RETURNING BEFORE.*
and
DELETE FROM foo ... RETURNING AFTER.*
?
The best summarize of dropping NEW/OLD keywords for this proposal was
proposed while IRC meeting:
create or replace function ft1(integer) returns integer language plpgsql
as $f$ <<x>> declare r rt1; begin select 1 as a into r; update rt1 r set
a = a + 1 returning XXX into r; raise notice 'r = %', r; return null;
end; $f$;
Regards,
Karol Trzcionka

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-02 19:41:59 Re: 9.3 Beta1 status report
Previous Message Tom Lane 2013-05-02 18:47:28 Re: GSOC13 proposal - extend RETURNING syntax