Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
Date
Msg-id 199910081630.MAA27953@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Bruce Momjian <maillist@candle.pha.pa.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)

No problem.  I just added test code to see if it works, and it does:
$result = $conn->exec("CREATE TABLE person (id int4, -- test\n name char(16)) -- test"); 

Tests embedded newline, and comment without newline.

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


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

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

> 
> 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. 
Maybe it does.  Anyway, changing all the interfaces would be a pain, and
non-portable to older releases.

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

If I change it to:
xqliteral       [\\](.|\n|\r)

then \r\n is not going to work, and if I change it to:
xqliteral       [\\](.|\n|\r)+

Then \n\n is going to be accepted when it shouldn't.  Seems I will have
to leave it alone for now.

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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: Top N queries and disbursion
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Features for next release