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@Fam-Meskes.De | Use PostgreSQL!