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
