| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Ian Barwick <ian(at)2ndquadrant(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: "RETURNING PRIMARY KEY" syntax extension |
| Date: | 2014-07-03 21:05:32 |
| Message-ID: | 2415.1404421532@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, Jul 3, 2014 at 7:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy
>> in that the application would have little idea what it was getting back.
>> IF EXISTS would make it so spongy as to be useless, IMO.
> Seems easy enough to look at the count of columns in the result set.
Sure, if you know how many columns are in the table to begin with; but
that goes back to having table metadata. If you don't, you're probably
going to be issuing "RETURNING *", and AFAICS "RETURNING *, PRIMARY KEY"
would be entirely useless (even without IF EXISTS :-().
I'm still unconvinced that there's a robust use-case here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-07-03 21:09:41 | Re: Pg_upgrade and toast tables bug discovered |
| Previous Message | Tom Lane | 2014-07-03 20:43:21 | Re: Array of composite types returned from python |