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 по дате отправления: