| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: The "char" type versus non-ASCII characters |
| Date: | 2021-12-09 13:27:20 |
| Message-ID: | 00b43a6d-3274-7e80-d323-9ff3a8183559@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03.12.21 21:13, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 12/3/21 14:42, Tom Lane wrote:
>>> Right, I envisioned that ASCII behaves the same but we'd use
>>> a numeric representation for high-bit-set values. These
>>> cases could be told apart fairly easily by charin(), since
>>> the numeric representation would always be three digits.
>
>> OK, this seems the most attractive. Can we also allow 2 hex digits?
>
> I think we should pick one base and stick to it. I don't mind
> hex if you have a preference for that.
I think we could consider char to be a single-byte bytea and use the
escape format of bytea for char. That way there is some precedent and
we don't add yet another encoding or escape format.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-12-09 13:31:23 | Re: Replace uses of deprecated Python module distutils.sysconfig |
| Previous Message | Andrew Dunstan | 2021-12-09 13:12:14 | Re: A test for replay of regression tests |