Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level?
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level? |
Дата | |
Msg-id | Pine.LNX.4.21.0002220002360.349-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level?
|
Список | pgsql-hackers |
On 2000-02-20, Tom Lane mentioned: > select *-- 123 > ERROR: Can't find left op '*--' for type 23 > select /**/- 22 > ERROR: parser: parse error at or near "" I believe that these things (certainly the first one) could be fixed by making the {operator} rule in scan.l rescanning yytext for "--" or "/*" (using string functions) and if found putting part of the token back in the input stream using yyless(). > Meanwhile, psql is using some ad-hoc code to recognize comments, > rather than a lexer, and it thinks both of these sequences are indeed > comments. Incidentally, it's right. ;) > I suggest we change psql to not strip -- comments either. That sounds reasonable, although we had a painful discussion about this last fall, I recall, that ended with me leaving it like that. If someone wants to bother, be my guest. One of these days, psql should get a lexer to fix some other parsing problems as well. > but <<EOF>> is a flex-ism not supported by regular lex. Exclusive start conditions are not supported by regular lex either. We lose. Sometimes I think we're actually doing people a favour by requiring flex, because then they don't have to deal with incarnations like Sun's. If you want to catch unbalanced quotes at the end of input, I could imagine that some grand unified evilness via yywrap setting some global flag or two might get the job done. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: