From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: MERGE ... RETURNING |
Date: | 2023-07-13 16:01:04 |
Message-ID: | 1223124bf7d13181ddb1a95aa81f72ed657682e1.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2023-01-09 at 12:29 +0000, Dean Rasheed wrote:
> > Would it be feasible to allow specifying old.column or new.column?
> > These would always be NULL for INSERT and DELETE respectively but
> > more useful with UPDATE. Actually I've been meaning to ask this
> > question about UPDATE … RETURNING.
> >
>
> I too have wished for the ability to do that with UPDATE ...
> RETURNING, though I'm not sure how feasible it is.
>
> I think it's something best considered separately though. I haven't
> given any thought as to how to make it work, so there might be
> technical difficulties. But if it could be made to work for UPDATE,
> it
> shouldn't be much more effort to make it work for MERGE.
MERGE can end up combining old and new values in a way that doesn't
happen with INSERT/UPDATE/DELETE. For instance, a "MERGE ... RETURNING
id" would return a mix of NEW.id (for INSERT/UPDATE actions) and OLD.id
(for DELETE actions).
The pg_merge_action() can differentiate the old and new values, but
it's a bit more awkward.
I'm fine considering that as a separate patch, but it does seem worth
discussing briefly here.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-07-13 16:03:21 | Re: sslinfo extension - add notbefore and notafter timestamps |
Previous Message | Pavel Luzanov | 2023-07-13 15:59:31 | Re: psql: Add role's membership options to the \du+ command |