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
