Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison

Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Ah, so the problem was that the perl interface didn't append a newline?
>> Good catch.  I don't like this fix, however, since I fear it will
>> alter behavior for the case where there is an embedded newline in the
>> query buffer.

> I will commit this so it will always be tested by the perl test code.

But how often do we run that?

> No, seems lex only goes the end-of-line unless you specifically say \n.

OK, I see in the flex manual that "." matches everything except newline,
so I guess it will work.  At least with flex.  But ".*" patterns with
no clearly defined terminator always make me itch --- it doesn't take
much change to get the wrong result.

>> A better solution IMHO is to leave scan.l as it was and instead
>> always append a \n to the presented query string before we parse.

> Problem here is that perl is not the only interface that would have this
> problem.  In fact, I am not sure why libpq doesn't have this problem. 

No, I wasn't suggesting patching the perl interface; I was suggesting
changing the backend, ie, adding the \n to the received query in
postgres.c just before we hand it off to the parser.

>> BTW, might be a good idea to add \r to that list of "space" characters
>> so we don't mess up on DOS-style newlines (\r\n).

> Interesting idea.  I tried that, but the problem is things like this:
>     xqliteral       [\\](.|\n)

Hmm, didn't think about what to do with \r inside literals.  I agree,
it's not worth trying to be smart about those, so I suppose ignoring
them outside literals would be inconsistent.  Still, how many people
try to enter newlines within literals?  Adding \r to the whitespace
set and nothing else might still be a useful compatibility gain.
        regards, tom lane