Re: quoting psql varible as identifier - Mailing list pgsql-hackers

From Tom Lane
Subject Re: quoting psql varible as identifier
Date
Msg-id 18628.1263932003@sss.pgh.pa.us
Whole thread Raw
In response to Re: quoting psql varible as identifier  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: quoting psql varible as identifier  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Do you think we should malloc 2n+X bytes all the time, or do you want
> to scan the string once to determine how much space is needed and then
> allocate exactly that much space?

I'd vote for two scans, as I think we'll soon decide 2n doesn't cut it
anyway.  One of the issues that needs to be looked at is embedded null
characters.  We might fail on that for the moment, but I can foresee
wanting to send \000 instead.  You don't want to pay for 4x do you?

> 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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Git out of sync vs. CVS
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: lock_timeout GUC patch