public inbox for [email protected]
help / color / mirror / Atom feedRe: Bug #866 related problem (ATTN Tom Lane)
3+ messages / 2 participants
[nested] [flat]
* Re: Bug #866 related problem (ATTN Tom Lane)
@ 2003-02-11 08:39 Florian Wunderlich <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Florian Wunderlich @ 2003-02-11 08:39 UTC (permalink / raw)
To: [email protected]; pgsql-docs
I can't get through to you because your spam filter blocks my SMTP
relay.
Tom Lane wrote:
>
> > I now have a quite similar problem: while a CURSOR on a SELECT for a
> > normal query works now, I encounter the same behavior for aggregate
> > queries:
>
> As I think I pointed out in the original discussion, backwards fetch
> doesn't work for most plan types more complex than a simple sequential
> or index scan. This is not trivial to fix.
>
> regards, tom lane
I've looked trough our exchange on the list, but there's nothing about
that.
I found another posting which I guess you mean
(http://archives.postgresql.org/pgsql-novice/2002-12/msg00222.php).
I have put a comment in the interactive documentation for now, quoting
your original mail. This really should be in the distributed
documentation for FETCH.
So can I be sure that every non-aggregate SELECT on tables joined with
unique indexes works, independent of the WHERE or ORDER BY?
Is anybody working on implementing this functionality?
Thanks,
Florian Wunderlich
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Bug #866 related problem (ATTN Tom Lane)
@ 2003-02-12 23:27 Tom Lane <[email protected]>
parent: Florian Wunderlich <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2003-02-12 23:27 UTC (permalink / raw)
To: Florian Wunderlich <[email protected]>; +Cc: [email protected]; pgsql-docs
Florian Wunderlich <[email protected]> writes:
> So can I be sure that every non-aggregate SELECT on tables joined with
> unique indexes works, independent of the WHERE or ORDER BY?
I would think that backwards scan on a join mostly doesn't work, but
haven't tried it in any detail.
A plan with a SORT node at the top *will* work, no matter what's under
the SORT, so ORDER BY might mask problems in some cases.
> Is anybody working on implementing this functionality?
Not me... although I have thought about at least adding enough code to
report an error in the cases that will give wrong answers.
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Bug #866 related problem (ATTN Tom Lane)
@ 2003-02-13 16:27 Florian Wunderlich <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Florian Wunderlich @ 2003-02-13 16:27 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]
Tom Lane wrote:
>
> Florian Wunderlich <[email protected]> writes:
> > So can I be sure that every non-aggregate SELECT on tables joined with
> > unique indexes works, independent of the WHERE or ORDER BY?
>
> I would think that backwards scan on a join mostly doesn't work, but
> haven't tried it in any detail.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2003-02-13 16:27 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-02-11 08:39 Re: Bug #866 related problem (ATTN Tom Lane) Florian Wunderlich <[email protected]>
2003-02-12 23:27 ` Tom Lane <[email protected]>
2003-02-13 16:27 ` Florian Wunderlich <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox