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: Robert Haas on 19 Jan 2010 16:25 On Tue, Jan 19, 2010 at 3:13 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> It seems to me that it might be >> sensible to do it this way: > >> 1. Do a locale-aware scan of the input string and count the number of >> characters we need to escape (num_to_escape). >> 2. If num_to_escape is 0, fast path: allocate len+3 bytes and use >> memcpy to copy the input data to the output buffer. >> 3. Otherwise, allocate len+num_to_escape+5 bytes >> (space-E-quote-quote-NUL) and do a second locale-aware scan of the >> input string, copying and escaping as we go (or do you only want the >> space-E if the escapable character that we find is \ rather than '?). > > Yeah, the fast path if no escaping is needed seems attractive. Cool. > I think that E should only be inserted if we have a backslash to deal > with; no reason to generate nonstandard syntax if we don't have to. > That would mean keeping two bits of state (escaping-needed and > malloc-size) from the initial pass, but that's pretty cheap. That's fine. I'd like to proceed by committing an initial patch which changes the "Escaping Strings for Inclusion in SQL Commands" to use a <variablelist> with one <varlistentry> per function (as we do in surrounding functions) and consolidates it with the following section, "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() as discussed here, and the doc diff hunks will actually be readable. Objections? If so, please state how you'd like to see the docs organized because I don't see another way to do it that makes any sense. ....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 19 Jan 2010 16:40 Robert Haas <robertmhaas(a)gmail.com> writes: > I'd like to proceed by committing an initial patch which changes the > "Escaping Strings for Inclusion in SQL Commands" to use a > <variablelist> with one <varlistentry> per function (as we do in > surrounding functions) and consolidates it with the following section, > "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll > submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() > as discussed here, and the doc diff hunks will actually be readable. Sounds like a plan. 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 19 Jan 2010 23:19 On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I'd like to proceed by committing an initial patch which changes the >> "Escaping Strings for Inclusion in SQL Commands" to use a >> <variablelist> with one <varlistentry> per function (as we do in >> surrounding functions) and consolidates it with the following section, >> "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll >> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() >> as discussed here, and the doc diff hunks will actually be readable. > > Sounds like a plan. Initial commit done, and follow-on patch attached. The docs took longer to write than the code. I spent a fair amount of time trying to make it all make sense, but suggestions are welcome. ....Robert
From: Robert Haas on 21 Jan 2010 10:00 On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> I'd like to proceed by committing an initial patch which changes the >>> "Escaping Strings for Inclusion in SQL Commands" to use a >>> <variablelist> with one <varlistentry> per function (as we do in >>> surrounding functions) and consolidates it with the following section, >>> "Escaping Binary Strings for Inclusion in SQL Commands". Then I'll >>> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() >>> as discussed here, and the doc diff hunks will actually be readable. >> >> Sounds like a plan. > > Initial commit done, and follow-on patch attached. The docs took > longer to write than the code. I spent a fair amount of time trying > to make it all make sense, but suggestions are welcome. Committed after fixing a couple of oversights in my doc changes. ....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 21 Jan 2010 11:57
2010/1/21 Robert Haas <robertmhaas(a)gmail.com>: > On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas(a)gmail.com> writes: >>>> I'd like to proceed by committing an initial patch which changes the >>>> "Escaping Strings for Inclusion in SQL Commands" to use a >>>> <variablelist> with one <varlistentry> per function (as we do in >>>> surrounding functions) and consolidates it with the following section, >>>> Â "Escaping Binary Strings for Inclusion in SQL Commands". Â Then I'll >>>> submit a patch implementing pqEscapeLiteral() and pqEscapeIdentifier() >>>> as discussed here, and the doc diff hunks will actually be readable. >>> >>> Sounds like a plan. >> >> Initial commit done, and follow-on patch attached. Â The docs took >> longer to write than the code. Â I spent a fair amount of time trying >> to make it all make sense, but suggestions are welcome. > > Committed after fixing a couple of oversights in my doc changes. thank you. I actualised patch I thing, we need one libpq change more. + static void + appendLiteral(PGconn *conn, PQExpBuffer buf, const char *str) + { + char *escaped_str; + size_t len; + + len = strlen(str); + escaped_str = PQescapeLiteral(conn, str, len); + + if (escaped_str == NULL) + { + const char *error_message = PQerrorMessage(pset.db); + + if (strlen(error_message)) + psql_error("%s", error_message); + } + else + { + appendPQExpBufferStr(buf, escaped_str); + free(escaped_str); + } + } the correct result of this function (when is some error) is broken buffer. But function markPQExpBufferBroken is static. Regards Pavel Stehule > > ...Robert > |