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 19:01:44 |
Message-ID: | 17185.1263927704@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:
> ... I think as
> long as we're adding a new function, we should make it behave sanely.
> We could even take the opportunity to go back and add a saner version
> of PQescapeStringConn.
Well, it's a bit late in the devel cycle to be inventing from scratch,
but if we did want to do something "saner" what would it look like?
I can see the following possibilities:
* include boundary quotes (and E too in the literal case). This would
imply telling people they should leave whitespace around the value in
the constructed query ... or should we insert leading/trailing spaces
to prevent that mistake too?
* malloc our own result value instead of expecting caller to provide
space. This adds another failure case (out of memory) but it's not
really much different from OOM on the caller side.
* anything else you want to change?
I suggest we could use PQescapeLiteral + PQescapeIdentifier as names
if we provide a new pair of functions defined with a different API.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-01-19 19:03:14 | Re: quoting psql varible as identifier |
Previous Message | Robert Haas | 2010-01-19 18:46:39 | Re: quoting psql varible as identifier |