Re: Re: Escaping strings for inclusion into SQL queries

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Weimer <Florian(dot)Weimer(at)RUS(dot)Uni-Stuttgart(dot)DE>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Escaping strings for inclusion into SQL queries
Date: 2001-09-04 00:40:38
Message-ID: Pine.LNX.4.30.0109040231390.4304-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-09-04 00:44:36 Re: Re: Escaping strings for inclusion into SQL queries
Previous Message Bruce Momjian 2001-09-04 00:16:52 Re: Bytea/Base64 encoders for libpq - interested?