Re: [HACKERS] FETCH without FROM/IN

Michael Meskes <meskes@postgreSQL.org> writes:
> On Wed, Jan 12, 2000 at 08:13:02PM -0500, Tom Lane wrote:
>> I think, though, that you could make our syntax work like
>> FETCH [ opt_direction fetch_how_many FROM/IN ] portal_name
>> without conflicts.  That'd be good since it'd be more like SQL92.

Note: I was assuming the same definitions of 'opt_direction' and
'fetch_how_many' as are in the current gram.y; namely, they can
expand to either an option phrase or empty.  So what I was really
saying is   FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name

> Yes. I just read the patch I got from Rene in detail and it seems to
> implement:

> FETCH [ <direction> [ <fetch_how_many> ]] [ FROM/IN ] portal_name;

Certainly we currently accept a how_many clause without a preceding
direction, so if the patch removes that possibility then it's wrong.

> However, I think it should be possible to make it:

> FETCH [ <direction> ][ <fetch_how_many> ] [ FROM/IN ] portal_name;

> This seems better, isn't it?

If you do it like that (ie, the portal name is now required), I *think*
it will work without shift-reduce conflicts in the current grammar,
but we may regret it later when we try to do more of SQL92.  I would
recommend sticking to an SQL92-like syntax, in which FROM/IN is not
optional if direction and/or how_many appear.

The reason I'm concerned about this is that all of the direction and
howmany keywords are considered valid ColIds (and if we take them out
of the ColIds list, we risk breaking databases that work at present).
That means that the parser has some difficulty in figuring out whether
an apparent keyword is really a keyword, or a portal name that happens
to be the same as a keyword.  For example, consider
FETCH NEXT;

If both FROM and portal_name were optional, this statement would
actually be ambiguous: is it FETCH NEXT from the default portal,
or FETCH with default options from a cursor named NEXT?

In the syntax you are proposing, this statement is valid and not
ambiguous --- NEXT must be a cursor name --- but the only way an
LR(1) parser can figure that out is to look ahead one token to see
that semicolon comes next.

What I'm concerned about is that SQL92 allows other options *after*
the cursor name, and we may someday want to support those.  We could
easily find that the grammar is no longer LR(1) (ie, it takes more than
one token lookahead to decide whether we have the portal name or not);
and then we've got trouble.  If FROM is required after FETCH options
then this risk is much reduced.

Another reason for requiring FROM/IN is that we will not be able to
expand the "FETCH n" syntax for how_many to handle a more general
expression (as opposed to a bare signed-integer constant, as we have
now) unless there is a delimiter between it and the portal name.
We still have unresolved headaches in the grammar that come from the
lack of delimiters around constant expressions in column DEFAULT
options; let's not add another source of the same kind of trouble.

In short, the syntax
   FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name

poses much less risk for future expansion than the syntax
   FETCH [ direction ] [ how_many ] [ FROM/IN ] portal_name

and that's why I think we'd be safer to stick with the former.
        regards, tom lane