From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ian Barwick <ian(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "RETURNING PRIMARY KEY" syntax extension |
Date: | 2014-06-09 14:46:09 |
Message-ID: | 28583.1402325169@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ian Barwick <ian(at)2ndquadrant(dot)com> writes:
> [ RETURNING PRIMARY KEY ]
It looks to me like this is coded to have the expansion of the "primary
key" done at parse time, which seems like fundamentally the wrong thing.
Consider a view or rule containing this clause; the pkey might be
different by the time execution rolls around. It'd be better probably
if the rewriter or planner did the expansion (and threw the error for
no-primary-key, if necessary).
Alternatively, we could do it like this and consider that the view is
dependent on the primary key constraint, but that seems inflexible.
BTW, it seems like your representation of the clause was rather poorly
chosen: it forces changing a whole lot of code that otherwise would
not need to be changed. I'd have left returningList alone and put the
returningPrimaryKey flag someplace else.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2014-06-09 14:49:03 | Re: NUMA packaging and patch |
Previous Message | Andres Freund | 2014-06-09 14:45:02 | Re: Inaccuracy in VACUUM's tuple count estimates |