Re: [HACKERS] FETCH without FROM/IN

On Thu, Jan 13, 2000 at 11:34:31AM -0500, Tom Lane wrote:
> FETCH [ [ direction ] [ how_many ] FROM/IN ] portal_name

Looks good to me.

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

Sure. Rene already send me a fix.

> 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,

Do we have a default portal?

> or FETCH with default options from a cursor named 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.

Yes, I completely agree on this one.

I will try to change the syntax to what you proposed.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael(at)Fam-Meskes(dot)De | Use PostgreSQL!