Re: Re: Escaping strings for inclusion into SQL queries - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Re: Escaping strings for inclusion into SQL queries
Date
Msg-id Pine.LNX.4.30.0109040231390.4304-100000@peter.localdomain
Whole thread Raw
In response to Re: Re: Escaping strings for inclusion into SQL queries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Escaping strings for inclusion into SQL queries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > A bug indeed.
>
> >  <xd>{xddouble} {
> > -                                       addlit(yytext, yyleng-1);
> > +                                       addlit(yytext+1, yyleng-1);
> >                                 }
>
> I don't follow.  xddouble can only expand to two quote marks, so how
> does it matter which one we use as the result?

addlit() expects the first argument to be null-terminated and implicitly
uses that null byte at the end of the supplied argument to terminate its
own buffer.  It expects to copy <doublequote><null> (new version), whereas
it got (old version) <doublequote><doublequote> and left the buffer
unterminated, which leads to random behavior, as you saw.

Since there are only a few calls to addlit(), I didn't feel like
re-engineering the whole interface to be prettier.  It does look like a
performance-beneficial implementation.

A concern related to the matter is that if you actually put such an
identifier into your database you basically make it undumpable (well,
unrestorable) because no place is prepared to handle such a thing.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Bytea/Base64 encoders for libpq - interested?
Next
From: Tom Lane
Date:
Subject: Re: Re: Escaping strings for inclusion into SQL queries