Re: Double newline bug with DBD::Pg: Where best to fix?
От | ivan |
---|---|
Тема | Re: Double newline bug with DBD::Pg: Where best to fix? |
Дата | |
Msg-id | 20010227124713.A3629@cleanwhisker.420.am обсуждение исходный текст |
Ответ на | Re: Double newline bug with DBD::Pg: Where best to fix? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-interfaces |
On Tue, Feb 27, 2001 at 03:21:58PM -0500, Tom Lane wrote: > Dan Lyke <danlyke@flutterby.com> writes: > > If, using DBI with DBD::Pg, you call > > > $dbh->do('INSERT INTO xyz(stuff) VALUES(' > > $dbh->quote("a string with \n\n a two line break").')'); > > > You'll get a string with a single line break back, because DBD::Pg > > doesn't escape newlines into '\n'. > > There shouldn't be any need to convert newlines into \n in quoted > strings; either way should work. > > > This is consistent with the interface via psql: > > > test=# insert into xyz(stuff) values('a string with > > test'# > > test'# a two line break'); > > test=# select stuff from xyz; > > stuff > > ---------------------------------- > > a string with > > a two line break > > (1 row) > > > (As you can see there are also some interesting issues with leading > > spaces going on here). > > I would call this a clear bug in psql. I cannot replicate the loss of > leading whitespace in current sources, but I do see the loss of the > empty line. Turning on debug logging shows that the empty line has > been stripped by psql, not the backend --- it's not there in the query > that arrives at the backend. > > I tried a similar experiment in pgtclsh and didn't see any loss of > blank lines, so the problem seems to be specific to psql. Your > observation in DBI must be an independent bug in either DBD::Pg or > DBI itself. > > > I don't have a copy of the SQL standard in front of me, so I'm not > > sure whether this needs to be fixed in the PostgreSQL parser (seems > > like the logical place, but we're into minutae of compatibility) or > > DBD::Pg (the easy place, but maybe this is a hack that's going to have > > to go in every interface). > > The Postgres parser is not broken, AFAICT. If you can find where this > is happening in the DBI/DBD path, please submit a patch. One of my cow orkers sent me a patch for this; it sounds like we tickled the same bug you did. See below. The other (unrelated) problem I'm having with DBD::Pg is that you can't insert more than 64k of data using placeholders, i.e. $sth = $dbh->prepare("INSERT INTO table VALUES ( ?, ?, ? )");$sth->execute($a, $b, $c); will *segfault* if $a $b or $c is larger than 64k. -- meow _ivan --- /tmp/dbd-pg/DBD-Pg-0.95/dbdimp.c Mon Jul 10 10:47:51 2000 +++ ./dbdimp.c Fri Feb 23 15:17:37 2001 @@ -634,9 +634,22 @@ if (in_literal) { /* check if literal ends but keep quotes in literal */ + if (dbis->debug) { + fprintf(DBILOGFP, "*src = %c, in_literal = %c, *(src+1) = %c\n", *src, in_literal, *(src+1)); + } +#if 1 + if (*src == in_literal) { + if (*(src+1) == in_literal) { + *dest++ = *src++; + } else { + in_literal = 0; + } + } +#else if (*src == in_literal && *(src-1) != '\\') { in_literal = 0; - } + } +#endif *dest++ = *src++; continue; } @@ -1022,9 +1035,21 @@ if (in_literal) { /* check if literal ends but keep quotes in literal */ + if (dbis->debug) { + fprintf(DBILOGFP, "*src = %c, in_literal = %c, *(src+1) = %c\n", *src, in_literal, *(src+1)); + } + if (*src == in_literal) { + if (*(src+1) == in_literal) { + *dest++ = *src++; + } else { + in_literal = 0; + } + } +#if 0 if (*src == in_literal && *(src-1) != '\\') { in_literal = 0; - } + } +#endif *dest++ = *src++; continue; }
В списке pgsql-interfaces по дате отправления: