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

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: luuk(at)wxs(dot)nl, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
Date: 1999-10-09 01:34:43
Message-ID: 199910090134.VAA22009@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 1999-10-09 02:05:55 Re: [HACKERS] Interesting Quote you might enjoy about PGSQL.
Previous Message Tom Lane 1999-10-08 23:14:24 Re: [HACKERS] Features for next release