| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 19:22:51 |
| Message-ID: | CAM-w4HO5tVe+ESd0JxoiEj3x4tMGJQwf_gRjWWDEy-_QwNmAkA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
But it seems like noise words -- if you don't put IF EXISTS then
surely you'll get the same behaviour anyways, no?
Fwiw when I wrote ORM-like layers I used to describe the output of the
query, including sometimes issuing WHERE 1<>0 queries and looking at
the output column types when I needed that before executing the query.
Using table metadata would have required a much more in depth
understanding of how the database worked and also wouldn't handle
expressions, joins, set operations, etc.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Gierth | 2014-07-03 19:26:55 | Re: Aggregate function API versus grouping sets |
| Previous Message | Greg Stark | 2014-07-03 18:51:40 | Re: tweaking NTUP_PER_BUCKET |