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 2 Jan 2010 13:53 2010/1/2 Tom Lane <tgl(a)sss.pgh.pa.us>: > 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. > Are we talking we about error handling in psql lexer? What I know, in psql there are no any escaping function now. Yes, exit(1) is maybe too hard - but it is safe. I didn't write PQescapeStringConn function, and I am not able to speak, we can ignore this error result. Full handling of this possible error, means to add some CHECK over any lexer call. Pavel > Â Â Â Â Â Â Â Â Â Â Â Â 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: Pavel Stehule on 2 Jan 2010 13:59 2010/1/2 Tom Lane <tgl(a)sss.pgh.pa.us>: > 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. > this code is taken from pg_dump, so if I understand it well, this is littl bit different case. > 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. > ok > 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. ok. Pavel > > Â Â Â Â Â Â Â Â Â Â Â Â 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: Pavel Stehule on 4 Jan 2010 05:44 hello 2010/1/2 Tom Lane <tgl(a)sss.pgh.pa.us>: > 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. > I am looking on psql directory. Now I found, so in this directory is linked dumputil.c - It could little bit to help us. I have one question. If I understand well, the function fmtId isn't multibyte safe? So why is possible to use it in pg_dump? Pavel > 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
From: Pavel Stehule on 4 Jan 2010 07:56 Hello I talked with Hitoshi Harada, and fmtId function is safe (minimally for Japanese case). This function working without any errors, so we must not duplicate a code. Pavel 2010/1/4 Pavel Stehule <pavel.stehule(a)gmail.com>: > hello > > 2010/1/2 Tom Lane <tgl(a)sss.pgh.pa.us>: >> 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. >> > > I am looking on psql directory. Now I found, so in this directory is > linked dumputil.c - It could little bit to help us. > > I have one question. If I understand well, the function fmtId isn't > multibyte safe? So why is possible to use it in pg_dump? > > Pavel > >> 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 >> >
From: Tom Lane on 4 Jan 2010 09:59
Pavel Stehule <pavel.stehule(a)gmail.com> writes: > I have one question. If I understand well, the function fmtId isn't > multibyte safe? So why is possible to use it in pg_dump? pg_dump is only guaranteed to work correctly in the server encoding. If you force it to use a client_encoding different from the server's, it might or might not work, for reasons far beyond that one --- the big problem usually is data containing characters that have no equivalent in the client encoding. So I'm not particularly excited about whether fmtId is multibyte safe within pg_dump. If we were to try to use it in more general contexts, it would probably need more work. 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 |