| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Encoding/collation question |
| Date: | 2019-12-12 13:35:53 |
| Message-ID: | 25766.1576157753@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> writes:
> Question: is C collation expected to be future-proof /
> rock-solid /stable -- like UTF8 for encoding choice -- or
> could it end up like the SQL-ASCII encoding did: Yeah, we
> support it, it's been in use a long time, it should work,
> but, nah, one doesn't really want to choose it over UTF8 if
> at all possible, or at least know *exactly* what one is doing
> and BTW YMMV ?
C collation basically devolves to strcmp/memcmp, which are as standard
and well-defined as can be. If you're happy with the way it sorts
things then there's no reason not to use it.
It's actually all the *other* collations where you should worry about
their behavior being a moving target :-(.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rich Shepard | 2019-12-12 13:37:59 | Re: Encoding/collation question |
| Previous Message | Karsten Hilbert | 2019-12-12 09:37:13 | Re: Encoding/collation question |