Re: quoting psql varible as identifier

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: quoting psql varible as identifier
Date: 2010-01-21 17:33:35
Message-ID: 603c8f071001210933t69537d32mb81244494bb8ac82@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 21, 2010 at 11:57 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2010/1/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Tue, Jan 19, 2010 at 11:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Jan 19, 2010 at 4:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Robert Haas <robertmhaas(at)gmail(dot)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.

markPQExpBufferBroken is specifically designed to handle out of memory
errors. I don't think we should try to generalize that to handle
encoding violations or other things, at least not without some very
careful thought about the consequences of so doing. I think we need
to find some other way of signalling an error back to the caller,
although it's not exactly obvious to me what the best way to do that
is.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-01-21 17:35:41 Re: 8.5 vs. 9.0, Postgres vs. PostgreSQL
Previous Message Jeff Davis 2010-01-21 17:21:56 Re: Listen / Notify - what to do when the queue is full