On 1/13/14, 5:57 PM, Josh Berkus wrote:
On 01/13/2014 03:41 PM, Florian Pflug wrote:
It therefor isn't an oversight that SELECT ... INTO allows multiple result rows
but INSERT/UPDATE/DELETE forbids them, it's been done that way on purpose and
for a reason. We shouldn't be second-guessing ourselves by changing that later -
not, at least, unless we have a *very* good reason for it. Which, AFAICS, we
don't.
(And yeah, personally I'd prefer if we'd complain about multiple rows. But it's
IMHO just too late for that)
I *really* don't want to go through all my old code to find places where
I used SELECT ... INTO just to pop off the first row, and ignored the
rest. I doubt anyone else does, either.
Do you regularly have use cases where you actually want just one RANDOM row? I
suspect the far more likely scenario is that people write code assuming they'll
get only one row and they'll end up with extremely hard to trace bugs if that
assumption is ever wrong.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
