From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dionisis Kontominas <dkontominas(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Question regarding UTF-8 data and "C" collation on definition of field of table |
Date: | 2023-02-06 01:30:25 |
Message-ID: | 2564482.1675647025@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dionisis Kontominas <dkontominas(at)gmail(dot)com> writes:
> 1. Regarding the different languages in the same column, that is normal
> if the column is a UTF-8 one, i.e. should be able to hold for example
> English, Greek and Chinese characters. In this case what is the best
> approach to define the collation and lctype of the column? Either C
> or ucs_basic maybe or something else or it does not matter, the characters
> would be stored correctly as long as the database is UTF8 encoding?
The characters will be stored correctly, yes. Collation only affects
sort order. Ctype affects some other functions like upper/lowercase
folding and what is considered a "letter" in regexps. If you use "C"
for lc_ctype then only ASCII letters will be folded or recognized as
letters.
> 2. Is there a real difference between C and ucs_basic collation/lctype?
No, at least not in Postgres.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Brockie | 2023-02-06 03:58:41 | Re: Slow down dev database transactions/second for testing? |
Previous Message | Peter Smith | 2023-02-06 01:16:58 | Re: Support logical replication of DDLs |