On Tue, Jan 19, 2010 at 3:13 PM, Tom Lane <tgl@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