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
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? |