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?


Weslee