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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(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-08 13:47:03
Message-ID: 2748.939390423@sss.pgh.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:
> *** src/backend/parser/scan.l 1999/09/28 03:41:36 1.57
> --- src/backend/parser/scan.l 1999/10/08 04:58:23
> ***************
> *** 167,173 ****
>
> param \${integer}
>
> ! comment ("--"|"//").*\n
>
> space [ \t\n\f]
> other .
> --- 167,173 ----
>
> param \${integer}
>
> ! comment ("--"|"//").*
>
> space [ \t\n\f]
> other .

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. For example
CREATE TABLE mytab -- comment \n (f1 int)
can be sent to the backend as one string (though not via psql). With
the above change in scan.l I think the comment will be taken to include
everything from -- to the end of the buffer, which is wrong.

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.

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).

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brook Milligan 1999-10-08 14:03:18 Re: [HACKERS] RI status report #4 (come and join)
Previous Message Ansley, Michael 1999-10-08 13:38:07 RE: [HACKERS] Re: Top N queries and disbursion