Re: quoting psql varible as identifier

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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-19 20:13:23
Message-ID: 18628.1263932003@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2010-01-19 20:15:46 Re: lock_timeout GUC patch
Previous Message Kevin Grittner 2010-01-19 20:07:53 Re: Git out of sync vs. CVS