| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com> |
| Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Pre-proposal: unicode normalized text |
| Date: | 2023-10-06 18:17:32 |
| Message-ID: | CA+TgmoYGrrOOahgxNO=W7_cvG-g--WVtuK6SYkWa+PEDdTOUqw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 6, 2023 at 1:38 PM Nico Williams <nico(at)cryptonector(dot)com> wrote:
> On Fri, Oct 06, 2023 at 01:33:06PM -0400, Robert Haas wrote:
> > On Thu, Oct 5, 2023 at 3:15 PM Nico Williams <nico(at)cryptonector(dot)com> wrote:
> > > Text+encoding can be just like bytea with a one- or two-byte prefix
> > > indicating what codeset+encoding it's in. That'd be how to encode
> > > such text values on the wire, though on disk the column's type should
> > > indicate the codeset+encoding, so no need to add a prefix to the value.
> >
> > Well, that would be making the encoding a per-value property, rather
> > than a per-column property like collation as I proposed. I can't see
>
> On-disk it would be just a property of the type, not part of the value.
I mean, that's not how it works.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nico Williams | 2023-10-06 18:25:44 | Re: Pre-proposal: unicode normalized text |
| Previous Message | Michał Kłeczek | 2023-10-06 17:55:08 | Re: FDW LIM IT pushdown |