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 4 Jan 2010 14:51 2010/1/4 Tom Lane <tgl(a)sss.pgh.pa.us>: > 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. I could agree with this explanation for quote_identifier function, but not in 100% for fmtId function. We can change encoding for pg_dump (option -E). I don't have a problem to write second and safe fmtId function (with technique used in dumputils don't need to modify libpq), although fmtId do exactly what I need. I would to understand to behave. 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: Robert Haas on 4 Jan 2010 23:12 On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > 2010/1/4 Tom Lane <tgl(a)sss.pgh.pa.us>: >> 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. > > I could agree with this explanation for quote_identifier function, but > not in 100% for fmtId function. We can change encoding for pg_dump > (option -E). But if it's not guaranteed to work, the fact that you can do it is irrelevant. > I don't have a problem to write second and safe fmtId > function (with technique used in dumputils don't need to modify > libpq), although fmtId do exactly what I need. I would to understand > to behave. I think you mean that you would need to understand how it should behave - in which case I agree, but I think Tom spelled that out pretty clearly upthread: close PQescapeStringConn and adapt it to be PQescapeIdentifier. ....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 4 Jan 2010 23:34 Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> I don't have a problem to write second and safe fmtId >> function (with technique used in dumputils don't need to modify >> libpq), although fmtId do exactly what I need. I would to understand >> to behave. > I think you mean that you would need to understand how it should > behave - in which case I agree, but I think Tom spelled that out > pretty clearly upthread: close PQescapeStringConn and adapt it to be > PQescapeIdentifier. The more important point here is that fmtId doesn't do "exactly what you need" in any case. fmtId is safe to use in pg_dump because pg_dump is only expected to work with the same or older version of the backend. It would not be safe to use it in libpq, which is expected to still work with newer backends that might have more reserved words. 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 5 Jan 2010 08:23 2010/1/5 Tom Lane <tgl(a)sss.pgh.pa.us>: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> I don't have a problem to write second and safe fmtId >>> function (with technique used in dumputils don't need to modify >>> libpq), although fmtId do exactly what I need. I would to understand >>> to behave. > >> I think you mean that you would need to understand how it should >> behave - in which case I agree, but I think  Tom spelled that out >> pretty clearly upthread: close PQescapeStringConn and adapt it to be >> PQescapeIdentifier. > > The more important point here is that fmtId doesn't do "exactly what you > need" in any case.  fmtId is safe to use in pg_dump because pg_dump is > only expected to work with the same or older version of the backend. > It would not be safe to use it in libpq, which is expected to still work > with newer backends that might have more reserved words. So I finnaly moved to libpq PQescapeIdentConn function patch is attached. regards Pavel > >             regards, tom lane >
From: Robert Haas on 10 Jan 2010 22:55
On Tue, Jan 5, 2010 at 8:23 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: > 2010/1/5 Tom Lane <tgl(a)sss.pgh.pa.us>: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> On Mon, Jan 4, 2010 at 2:51 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>>> I don't have a problem to write second and safe fmtId >>>> function (with technique used in dumputils don't need to modify >>>> libpq), although fmtId do exactly what I need. I would to understand >>>> to behave. >> >>> I think you mean that you would need to understand how it should >>> behave - in which case I agree, but I think Tom spelled that out >>> pretty clearly upthread: close PQescapeStringConn and adapt it to be >>> PQescapeIdentifier. >> >> The more important point here is that fmtId doesn't do "exactly what you >> need" in any case. fmtId is safe to use in pg_dump because pg_dump is >> only expected to work with the same or older version of the backend. >> It would not be safe to use it in libpq, which is expected to still work >> with newer backends that might have more reserved words. > > So I finnaly moved to libpq PQescapeIdentConn function > > patch is attached. No longer applies, please rebase. Thanks, ....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 |