Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Has this been resolved? Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: 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. Hmm, so I see: /* append data --- note we assume ytext is null-terminated */ memcpy(literalbuf+literallen, ytext, yleng+1); literallen += yleng; Given that we are passing the length of the desired string, it seems bug-prone for addlit to *also* expect null termination. I'd suggest memcpy(literalbuf+literallen, ytext, yleng); literallen += yleng; literalbuf[literallen] = '\0'; instead. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Bruce Momjian [EMAIL PROTECTED] writes: Has this been resolved? Peter applied his patch, but I am planning to also change addlit to not require null termination, because I believe we'll get bit again if we don't. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Peter Eisentraut [EMAIL PROTECTED] writes:
Florian Weimer writes:
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
Last time I checked (15 seconds ago), you could not escape with \ in
PostgreSQL. The identifer parsing rules are a bit different from strings.
Yes, we misread the lexer description. I'm sorry about that.
In addition, there seems to be a bug in the treatment of escapes in
identifiers. 'SELECT ;' yields the error message 'Attribute ''
not found ' (not ''!) or even 'Attribute '\' not found', depending
on the queries executed before.
For identifiers, comparing the characters to a white list is probably
a more reasonable approach.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Bruce Momjian [EMAIL PROTECTED] writes: OK, can you supply an updated patch? Yes, I'm going to update it. Shall I post it here? Sure, or patches list. Could anybody have a look at the parser issue? I am unsure how it is supposed to behave. Comments? Does the standard say anything? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
OK, can you supply an updated patch?
Peter Eisentraut [EMAIL PROTECTED] writes:
Florian Weimer writes:
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
Last time I checked (15 seconds ago), you could not escape with \ in
PostgreSQL. The identifer parsing rules are a bit different from strings.
Yes, we misread the lexer description. I'm sorry about that.
In addition, there seems to be a bug in the treatment of escapes in
identifiers. 'SELECT ;' yields the error message 'Attribute ''
not found ' (not ''!) or even 'Attribute '\' not found', depending
on the queries executed before.
For identifiers, comparing the characters to a white list is probably
a more reasonable approach.
--
Florian Weimer [EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Florian Weimer writes:
In addition, there seems to be a bug in the treatment of escapes in
identifiers. 'SELECT ;' yields the error message 'Attribute ''
not found ' (not ''!) or even 'Attribute '\' not found', depending
on the queries executed before.
A bug indeed.
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/parser/scan.l,v
retrieving revision 1.88
diff -u -r1.88 scan.l
--- scan.l 2001/03/22 17:41:47 1.88
+++ scan.l 2001/09/03 22:11:46
@@ -375,7 +375,7 @@
return IDENT;
}
xd{xddouble} {
- addlit(yytext, yyleng-1);
+ addlit(yytext+1, yyleng-1);
}
xd{xdinside} {
addlit(yytext, yyleng);
===end
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Peter Eisentraut [EMAIL PROTECTED] 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? This seems unlikely
to change the behavior. If it does, I think the real bug is elsewhere.
I do see a bug here --- I get
regression=# select ;
NOTICE: identifier [ lots o' rubouts ] @;Ç will
be truncated to
ERROR: Attribute '' not found
regression=#
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Tom Lane writes:
Peter Eisentraut [EMAIL PROTECTED] 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 doublequotenull (new version), whereas
it got (old version) doublequotedoublequote 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 [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: 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. Hmm, so I see: /* append data --- note we assume ytext is null-terminated */ memcpy(literalbuf+literallen, ytext, yleng+1); literallen += yleng; Given that we are passing the length of the desired string, it seems bug-prone for addlit to *also* expect null termination. I'd suggest memcpy(literalbuf+literallen, ytext, yleng); literallen += yleng; literalbuf[literallen] = '\0'; instead. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Florian Weimer writes:
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
Last time I checked (15 seconds ago), you could not escape with \ in
PostgreSQL. The identifer parsing rules are a bit different from strings.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Escaping strings for inclusion into SQL queries
On Wed, Aug 22, 2001 at 05:16:44PM +, Florian Weimer wrote: We therefore suggest that a string escaping function is included in a future version of PostgreSQL and libpq. A sample implementation is provided below, along with documentation. I use Perl, which (through DBD::Pg) has a quote function available, but I think this is a very good idea to include in the library. I only have one issue - the SQL standard seems to support the use of '' to escape a single quote, but not \'. Though PostgreSQL has an extended notion of character string literals, I think that the usual policy of using the standard interface when possible should apply. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Escaping strings for inclusion into SQL queries
Christopher Masto [EMAIL PROTECTED] writes:
I only have one issue - the SQL standard seems to support the use
of '' to escape a single quote, but not \'. Though PostgreSQL has
an extended notion of character string literals, I think that the
usual policy of using the standard interface when possible should
apply.
The first version escaped ' with ''. I changed it when I noticed that
if \' is used instead, the same function can be used for strings
('...') and identifiers (...).
In addition, you have to replace \ with \\, so you are forced
to leave the grounds of the standard anyway.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
