RE: CURSOR after hitting end

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: CURSOR after hitting end
Date: 2000-04-04 23:59:35
Message-ID: 000801bf9e91$d42f9d40$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Bruce Momjian
>
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > We have this in the CURSOR documentation:
> > > Once all rows are fetched, every other fetch access
> > > returns no rows.
> >
> > > Is this still true?
> >
> > Not if you then move or fetch backwards, I should think...
>
> No, it works. I think Tatsuo fixed it. After a FETCH ALL, I did this,
> and it worked:
>

This is true and false.
For index scan I fixed it before 6.5 and for sequential scan
I fixed it before 7.0.

However there remains some type of scan that returns no rows
after hitting end.
Especially for GROUP BY,*fetch backward* doesn't work well
fundamentally. I have known this but I've never seen bug
reports for this. It's not so easy to fix this and it wouldn't be
an effective way to scan base relation again for *GROUP BY*.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-04-05 00:05:41 Re: ERROR: No one parent tuple was found
Previous Message Bruce Momjian 2000-04-04 20:47:19 Re: Indexes growing continuously