From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | "Boguk, Maksym" <maksymb(at)fast(dot)au(dot)fujitsu(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Arulappan, Arul Shaji" <arul(at)fast(dot)au(dot)fujitsu(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal - Support for National Characters functionality |
Date: | 2013-07-31 17:43:18 |
Message-ID: | 20130731174318.GY14652@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Boguk, Maksym escribió:
> I think I give a wrong description there... it will be not GUC but
> GUC-type value which will be initialized during CREATE DATABASE and will
> be read only after, very similar to the lc_collate.
> So I think name national_lc_collate will be better.
> Function of this value - provide information about the default collation
> for the NATIONAL CHARACTERS inside the database.
> That's not limits user ability of use an alternative collation for
> NATIONAL CHARACTERS during create table via COLLATE keyword.
This seems a bit odd. I mean, if I want the option for differing
encodings, surely I need to be able to set them for each column, not at
the database level.
Also, as far as I understand what we want to control here is the
encoding that the strings are in (the mapping of bytes to characters),
not the collation (the way a set of strings are ordered). So it doesn't
make sense to set the NATIONAL CHARACTER option using the COLLATE
keyword.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-07-31 18:50:41 | Re: Review: UNNEST (and other functions) WITH ORDINALITY |
Previous Message | Alvaro Herrera | 2013-07-31 17:36:24 | Re: Backup throttling |