Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level? |
Дата | |
Msg-id | 22188.951193168@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: SQL compliance - why -- comments only at psql level? (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > On 2000-02-20, Tom Lane mentioned: >> select *-- 123 >> ERROR: Can't find left op '*--' for type 23 > 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(). I think you are right, that would work. Is yyless flex-specific or a generic lex feature? The intermediate-lookahead-buffer solution might still be better, if it lets us solve more problems than just this one. I'm inclined to not do anything until Thomas decides what he wants to do about the NOT NULL business. >> but <<EOF>> is a flex-ism not supported by regular lex. > Exclusive start conditions are not supported by regular lex either. Oooh, somehow I managed to completely miss that statement in the flex manual, but you are right. Hmm. I think that shoots a gaping hole in my desire to have scan.l work with plain lex. Offhand I don't see a good way to avoid using exclusive start conditions for multi-section literals. > 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. Right at the moment I'm thinking we might as well use <<EOF>>, which is after all the recommended way of doing it. regards, tom lane
В списке pgsql-hackers по дате отправления: