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