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 10 Jan 2010 23:22 2010/1/11 Robert Haas <robertmhaas(a)gmail.com>: > 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. ok I'll do it today Pavel > > 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
From: Pavel Stehule on 11 Jan 2010 06:54 Hello > > No longer applies, please rebase. > fixed, sorry Pavel > Thanks, > > ...Robert >
From: Robert Haas on 14 Jan 2010 20:46 On Mon, Jan 11, 2010 at 6:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> No longer applies, please rebase. > > fixed, sorry Hmm. I think that pqEscapeIdentConn should be in a separate section of the documentation, entitled "Escaping Identifiers for Inclusion in SQL Commands". Or else we should merge the existing sections "Escaping Strings for Inclusion in SQL Commands" and "Escaping Binary Strings for Inclusion in SQL Commands" and then put this in there too. On a perhaps-related note, does anyone understand why "Escaping Strings for Inclusion in SQL Commands" is formatted in a way that is needlessly inconsistent with the preceding and following sections? I was surprised by the magnitude of the doc diff hunk in this patch, but when I looked at it it seems to read more clearly with these changes. I have yet to fully review the code but on a quick glance it looks reasonable. ....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 15 Jan 2010 00:47 2010/1/15 Robert Haas <robertmhaas(a)gmail.com>: > On Mon, Jan 11, 2010 at 6:54 AM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >>> No longer applies, please rebase. >> >> fixed, sorry > my idea was: * string * escape_string * escape_ident * bytea * escape_bytea But I am not strong in it. Maybe this part of doc needs more love - long time there are doc to deprecated functions. It could be moved. Pavel > Hmm. Â I think that pqEscapeIdentConn should be in a separate section > of the documentation, entitled "Escaping Identifiers for Inclusion in > SQL Commands". Â Or else we should merge the existing sections > "Escaping Strings for Inclusion in SQL Commands" and "Escaping Binary > Strings for Inclusion in SQL Commands" and then put this in there too. > > On a perhaps-related note, does anyone understand why "Escaping > Strings for Inclusion in SQL Commands" is formatted in a way that is > needlessly inconsistent with the preceding and following sections? Â I > was surprised by the magnitude of the doc diff hunk in this patch, but > when I looked at it it seems to read more clearly with these changes. > > I have yet to fully review the code but on a quick glance it looks reasonable. > > ...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: Robert Haas on 16 Jan 2010 13:47
On Thu, Jan 14, 2010 at 8:46 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > I have yet to fully review the code but on a quick glance it looks reasonable. On further review, it looks less reasonable. :-( The new PQescapeIdentConn function is basically a cut-up version of PQescapeStringInternal, which seems like a reasonable foundation, but it rips out a little too much - specifically: 1. the length argument, 2. the size_t return value, 3. the portion of the handling for incomplete multibyte characters that prevents us from overrunning the output buffer on a maliciously constructed (or unlucky) input string, and 4. some relevant comments. I'm inclined to think we should put all of that stuff back, but certainly #3 at a minimum. ....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 |