2009/12/30 Robert Haas <robertmh...@gmail.com>: > On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> here is patch > > The error handling in quote_literal() doesn't look right to me. The > documentation for PQescapeStringConn says that it stores an error > message in the conn object, but your code ignores that and prints out > a generic message instead. That doesn't seem right: but then it > further goes on to call exit(1), which seems like a considerable > overreaction to an encoding violation, which is apparently the only > class of error PQescapeStringConn() is documented to throw.
Actually I am not sure about the adequate solution. Now, the lexer doesn't return any error. Any handled errors are fatal, and lexer (and psql) is finished with exit(1) - so there are not checking status after any lexer call. It is question if we have to do it. Because error will be raised in next stage: "Presently the only possible error conditions involve invalid multibyte encoding in the source string. The output string is still generated on error, but it can be expected that the server will reject it as malformed. On error, a suitable message is stored in the conn object, whether or not error is NULL." http://www.postgresql.org/docs/8.4/static/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING so probably - we can quietly ignore this error without security or functionality issues. I see two solution: a) print correct message and exit(1) b) quietly ignore this error - it's more warning than error, because error will be raised immediately Third variant, checking lexer status over every call is maybe non adequate to frequency of this error and an importance of this patch. I am for a. Regards, and happy new year Pavel > > ...Robert > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
