| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Correctly producing array literals for prepared statements |
| Date: | 2011-02-23 15:16:32 |
| Message-ID: | 4D6524D0.5040000@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02/23/2011 10:09 AM, Peter Geoghegan wrote:
> On 23 February 2011 04:36, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> This is only true for server encodings. In a client library I think
>> you lose on this and do have to deal with it. I'm not sure what client
>> encodings we do support that aren't ascii-supersets though, it's
>> possible none of them generate quote characters this way.
> I'm pretty sure all of the client encodings Tatsuo mentions are ASCII
> supersets. The absence of by far the most popular non-ASCII superset
> encoding, UTF-16, as a client encoding indicated that to me. It isn't
> byte oriented, and Postgres is.
They are not. It's precisely because they are not that they are not
allowed as server encodings.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-02-23 15:19:27 | Re: Binary in/out for aclitem |
| Previous Message | Robert Haas | 2011-02-23 15:10:07 | Re: WIP: cross column correlation ... |