Re: Hmm, nodeUnique doesn't really support backwards scan too well

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Hmm, nodeUnique doesn't really support backwards scan too well
Date: 2008-08-06 14:39:55
Message-ID: 13272.1218033595@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
> fetch backwards much or at all suddenly gets a much more expensive plan than
> if they didn't.

Well, what are they using SCROLL for if they don't need it?

A more plausible objection is that previously, (some) cursors using
SELECT DISTINCT would support backwards fetch even if you hadn't said
SCROLL. The bug I'm concerned about is only manifest with SELECT
DISTINCT ON, so someone might well be happily using DISTINCT in a way
that is affected. So there might be apps out there that are working
today and will stop working after this change. But they are very
clearly breaking the rules so I don't have a huge amount of sympathy for
them. If we were to take this argument seriously, it would mean that
we'd have to not only complicate ExecUnique but back-patch the result
clear back to 7.4. I'm not even sure how to fix it (the nasty case
is changing directions partway through the scan); let alone how to
fix it in a way that's obviously enough right to make me feel
comfortable in back-patching.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message paull 2008-08-06 14:48:27 BUG #4342: upper, lower, initcap do not work with umlaute?
Previous Message Lampa 2008-08-06 14:33:55 BUG #4341: planner doesn't using index for = operation