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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
Дата
Msg-id 2748.939390423@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Re: [GENERAL] Re: [PHP3] Re: PostgreSQL vs Mysql comparison
Список 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 exampleCREATE 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Ansley, Michael"
Дата:
Сообщение: RE: [HACKERS] Re: Top N queries and disbursion
Следующее
От: Brook Milligan
Дата:
Сообщение: Re: [HACKERS] RI status report #4 (come and join)