On 2/4/15 12:27 PM, Andres Freund wrote:
On 2015-02-04 12:23:51 +0100, Marko Tiikkaja wrote:
On 2/4/15 12:13 PM, Stephen R. van den Berg wrote:
If you know beforehand the query might generate more than one row (SELECT)
yet you also know that you are not interested in those, then maxrows=1
is best; then again, modifying the query to include a LIMIT 1 is even
better, in which case maxrows can be zero again.
This seems to be a common pattern, and I think it's a *huge* mistake to
specify maxrows=1 and/or ignore rows after the first one in the driver
layer. If the user says "give me the only row returned by this query", the
interface should check that only one row is in reality returned by the
query
I don't think these are what this thread is about. It's about a UPDATE
(=> no LIMIT) where the user uses a driver interface that doesn't return
rows generated by the UPDATE (the above error check doesn't make sense).
No, this wasn't what OP was on about. But I was merely responding to
the quoted paragraph, which suggested that maxrows=1 would be something
to consider for SELECT. Which I really strongly believe is not, and I'm
hoping we can eliminate it from all interfaces by 2025.
So slightly off-topic, for which I apologize.
.m
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
