FETCH statement again
От | Michael Meskes |
---|---|
Тема | FETCH statement again |
Дата | |
Msg-id | 20000113153916.B1071@fam-meskes.de обсуждение исходный текст |
Список | pgsql-hackers |
I just got a reply from the original author of the patch I was talking about: ----- Forwarded message from Rene Hogendoorn <hogend@nlr.nl> ----- From: Rene Hogendoorn <hogend@nlr.nl> Date: Thu, 13 Jan 2000 14:23:08 +0100 (MET) To: Michael Meskes <michael@fam-meskes.de> Subject: Re: ECPG patches TL> Michael Meskes <meskes@postgreSQL.org> writes: >> <fetch statement> ::= FETCH [ [ <fetch orientation> ] FROM ] >> <cursor name> INTO <fetch target list> >> To me this seems to say that FROM is just optional. Okay, if I >> make it optional in our parser? TL> Careful --- notice that FROM is only optional if you *also* TL> omit all the preceding optional clauses. Otherwisethere will TL> be a reduce conflict that you could only resolve by removing TL> all of FETCH's secondary keywordsfrom the ColId list. I TL> don't think that would be an acceptable tradeoff. The reduce conflict is caused by the /* EMPTY */ alternatives of 'opt_direction', 'fetch_how_many' and 'opt_portal_name'. Considering the sql92 syntax, 'opt_portalname' is wrong; the portalname is not optional, but required. Requiring a portalname also solves the problem of 'EXEC SQL FETCH; being a valid statement. Furthermore, at least INFORMIX supports 'FETCH NEXT t1;'. So, I strongly suggest to NOT require 'FROM'. ... Regards Rene -- R. A. Hogendoorn E-mail: hogend@nlr.nl Information and Communication Technology Division Tel. +31-527-24-8367 National Aerospace Laboratory, The Netherlands Fax. +31-527-24-8210 ----- End forwarded message ----- 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!
В списке pgsql-hackers по дате отправления: