Skip site navigation (1) Skip section navigation (2)

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 (view raw or whole 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

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group