> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> 
> 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

Yes, that is our idea too. For the sql syntax

Create table tbl1 (col1 nchar);

What should be the encoding and collation for col1? Because the idea is to have 
them in separate encoding and collation (if needed) from that of the rest of 
the table.  We have options of 

a) Having guc variables that will determine the default encoding and collation 
for nchar/nvarchar columns. Note that the collate variable is default only. 
Users can still override them per column.
b) Having the encoding name and collation as part of the syntax. For ex., (col1 
nchar encoding UTF-8 COLLATE "C"). Ugly, but.....
c) Be rigid and say nchar/nvarchar columns are by default UTF-8 (or something 
else). One cannot change the default. But they can override it when declaring 
the column by having a syntax similar to (b)


Rgds,
Arul Shaji



> (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




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to