Re: [HACKERS] Status report: long-query-string changes - Mailing list pgsql-hackers

From Leon
Subject Re: [HACKERS] Status report: long-query-string changes
Date
Msg-id 37DD4046.51780F00@udmnet.ru
Whole thread Raw
In response to Re: [HACKERS] Status report: long-query-string changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 
> Leon <leon@udmnet.ru> writes:
> >> A simple fix would be to check the current size after lexing of that
> >> accumulated string buffer, and if it is non-zero then elog(ERROR) a
> >> complaint. Perhaps a more general fix would be to ensure that you are
> >> never in an exclusive state after all tokens are processed, but I'm
> >> not sure how to do that.
> 
> > The solution is obvious - to eliminate exclusive states entirely!
> > Banzai!!!
> 
> Can we do that?  Seems like a more likely approach is to ensure that
> all of the lexer states have rules that ensure they terminate (or
> raise an error, as for unterminated quoted string) at end of input.
> I do think checking the token buffer is a hack, and changing the rules
> a cleaner solution...

Hmm, yea, you are right. It is much simpler solution. We can check 
condition in myinput() and input() when we are going to return 
end-of-input (YYSTATE == INITIAL), and raise an error if that's not so.
Well, I give up my idea of total extermination of start conditions :)

BTW, while eyeing the scan.l again, I noticed that C - style comments
can also contain bugs, but I am not completely sure.
-- 
Leon.
-------
He knows he'll never have to answer for any of his theories actually 
being put to test. If they were, they would be contaminated by reality.


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Fixing Simms' vacuum problems