From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: MOVE LAST: why?
Date: Wed, 08 Jan 2003 00:06:15 -0500
Message-ID: <1082.1042002375@sss.pgh.pa.us> (raw)
In-Reply-To: <3E1BAFF6.B0114A67@tpf.co.jp>
References: <200301072329.h07NT2X28922@candle.pha.pa.us>
<27934.1041984327@sss.pgh.pa.us>
<3E1B9DCD.75859501@tpf.co.jp>
<501.1041997832@sss.pgh.pa.us>
<3E1BA5E6.9463718F@tpf.co.jp>
<863.1042000401@sss.pgh.pa.us>
<3E1BAFF6.B0114A67@tpf.co.jp>
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> FETCH LAST should return the last one row.
That's not clear to me. Generally, I would think the cursor should
remain positioned on whatever row is returned, but the spec clearly says
that the final cursor position after FETCH LAST is *after* the last row.
Nor do I see where exactly it says that the last row is the one to
return in this case; the spec seems to treat LAST the same as PRIOR, so
that the *first* row encountered in the movement direction might be the
one to return. Can you disentangle the spec wording for me?
> FETCH RELATIVE m should return a row after skipping
> m rows if we follow the SQL standard and so the current
> implementation of FETCH RELATIVE is broken.
No objection to that here. Are you volunteering to make it do that?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, Inoue@tpf.co.jp, pgman@candle.pha.pa.us, pgsql-hackers@postgresql.org
Subject: Re: MOVE LAST: why?
In-Reply-To: <1082.1042002375@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox