> 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?
Well, at least it is there now, and I will do --with-perl here, so it
will be run.
> > 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.
True, but it fixes the problem.
>
> >> 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.
I try to avoid hacks like that if I can. Removing \n from the comment
termination is much clearer and more limited.
>
> >> 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.
Added \r to the {space} pattern.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
