Re: [HACKERS] Status report: long-query-string changes

From: Leon <leon(at)udmnet(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Status report: long-query-string changes
Date: 1999-09-13 18:19:50
Message-ID: 37DD4046.51780F00@udmnet.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Leon <leon(at)udmnet(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 1999-09-13 18:22:40 Re: [HACKERS] Fixing Simms' vacuum problems
Previous Message Lamar Owen 1999-09-13 18:00:07 Re: [HACKERS] Re: HISTORY for 6.5.2