| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org>, Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: plpgsql.consistent_into |
| Date: | 2014-01-13 23:57:53 |
| Message-ID: | 52D47D81.2010404@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2014-01-14 00:03:18 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Previous Message | Tom Lane | 2014-01-13 23:55:39 | Re: Hot standby 9.2.6 -> 9.2.6 PANIC: WAL contains references to invalid pages |