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