Weslee Bilodeau <weslee.bilodeau at hypermediasystems.com> writes:
> Christopher Browne wrote:
>> "Dmitry Koterov" <dmitry at koterov.ru> writes:
>>> The quick & dirty fix for the first one is:
>>> slony1-1.2.9\src\parsestatements\scanner.c
>>> if (state == Q_NORMAL_STATE) {
>>>     state = Q_HOPE_TO_DASH;
>>>     break;
>>> }
>>> replace to
>>> if (state == Q_NORMAL_STATE && extended_statement[cpos+1] == '-') {
>>>     state = Q_HOPE_TO_DASH;
>>>     break;
>>> }
>> 
>> I was going to object on the basis of "what if we're at the end of the string?"
>> 
>> The string is expected to end with a NULL, so if we've got a dash in
>> the present position, we can be pretty confident that there will be at
>> least one more byte in the string.  So I'm OK with that...
>> 
>> I'm not sure what's up with the "folding" of backslashes; the output
>> from test-scanner seems fine.
>> 
>> Below is the patch, as it stands now...
>> 
>
> Small question on this.
>
> I would imagine one could easily find a lot of edge cases that can break
> the current parser.
>
> I'm guessing they found them in psql, which is why psql stole the lexer
> from the backend itself.
>
> Is there any reason why slony didn't go the same route?
>
> http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/psqlscan.l?rev=1.21;content-type=text%2Fx-cvsweb-markup
>
> It was written for the exact same task -
>
> ------------------------------------------------------------
> This code is mainly needed to determine where the end of a SQL statement
> is: we are looking for semicolons that are not within quotes, comments,
> or parentheses.  The most reliable way to handle this is to borrow the
> backend's flex lexer rules, lock, stock, and barrel.  The rules below
> are (except for a few) the same as the backend's, but their actions are
> just ECHO whereas the backend's actions generally do other things.
> ------------------------------------------------------------
>
>
> Or has this already been discussed and dismissed?

If memory serves, I initially tried to introduce a second parser, but
ran into trouble with the notion of linking in 2 parsers.

I then reviewed syntax, and figured I had enough of it covered, which
was apparently not correct.

I'll take another crack at it...
-- 
"cbbrowne","@","ca.afilias.info"
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)