From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl>, Shay Rojansky <roji(at)roji(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fetch zero result rows when executing a query? |
Date: | 2015-02-04 11:36:25 |
Message-ID: | 54D20439.6010701@joh.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen R. van den Berg | 2015-02-04 11:36:56 | Re: Fetch zero result rows when executing a query? |
Previous Message | Marko Tiikkaja | 2015-02-04 11:34:19 | Re: Fetch zero result rows when executing a query? |