quoting psql varible as identifier
in [PgSql]
|
Prev: Port for Microsoft Services for Unix (SFU) or SUA
Next: [HACKERS] solution to make static changes in pg_hba.conf file?
From: Pavel Stehule on 29 Dec 2009 15:19 hello here is patch pavel(a)postgres:5432=# \set foo 'hello world' pavel(a)postgres:5432=# SELECT :'foo' AS :"foo"; hello world ------------- hello world (1 row) Regards Pavel 2009/12/29 Pavel Stehule <pavel.stehule(a)gmail.com>: > 2009/12/29 Tom Lane <tgl(a)sss.pgh.pa.us>: >> Pavel Stehule <pavel.stehule(a)gmail.com> writes: >>> 2009/12/29 Alvaro Herrera <alvherre(a)commandprompt.com>: >>>> Can we use a trick similar to pg_dump's? >> >>> I see it - we can move function (content) fmtId from dumputils.c to libpq. >> >> This is not a good idea. Â pg_dump can be expected to be up-to-date with >> the backend's keyword list, but libpq cannot. >> >> Just quote the thing unconditionally. Â It's not worth working harder >> than that anyway. > > I see it. > > Pavel > >> >> Â Â Â Â Â Â Â Â Â Â Â Â regards, tom lane >> >
From: Robert Haas on 30 Dec 2009 16:37 On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule <pavel.stehule(a)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. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 2 Jan 2010 13:10 2009/12/30 Robert Haas <robertmhaas(a)gmail.com>: > On Tue, Dec 29, 2009 at 3:19 PM, Pavel Stehule <pavel.stehule(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 2 Jan 2010 13:41 Pavel Stehule <pavel.stehule(a)gmail.com> writes: > a) print correct message and exit(1) Which part of "no, you're not doing that" wasn't clear to you? The error handling in this function should be no different from that in the existing escaping functions. exit(1) is completely unacceptable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 2 Jan 2010 13:53
Pavel Stehule <pavel.stehule(a)gmail.com> writes: > here is patch I looked at this patch a bit, and I think the real problem with it is that it's not multibyte safe. You've copied backend code that is allowed to assume it's in a safe encoding (ie, one where multibyte characters can't contain non-high-bit-set bytes). This is not okay on the client side, see SJIS and similar encodings. Where you need to start out is by cloning PQescapeStringConn, which does a similar type of transformation correctly even in unsafe encodings. I think we'd agreed upthread that libpq should provide PQescapeIdentifier functionality anyhow. Once you've actually read that code, you'll realize that it's okay to treat the error result as a warning, which resolves the other point of concern. Just print the message and use the result anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |