From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | CREATE COLLATION definitional questions for ICU |
Date: | 2017-06-25 15:45:28 |
Message-ID: | 10962.1498405528@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Reading over DefineCollation, I wondered:
* Should not the FROM code path copy the old collation's version?
It seems a little bit weird that "cloning" a collation takes the
liberty of installing a new version.
* Also (and this would be a pre-existing bug), why doesn't the FROM
path copy the old collation's encoding? For example, if you attempted
to clone the "C" encoding, you wouldn't get a true clone but something
that's specific to the current DB's encoding.
* For an ICU collation, should we not insist that collcollate and
collctype be equal? If not, what does it mean for them to be different?
* Now that it's possible for user-created collations to have encoding -1,
I do not think that the "shadowing" tests in CollationCreate and
IsThereCollationInNamespace are sufficient. They don't prevent a new
collation with encoding -1 from shadowing an existing encoding-specific
collation that doesn't happen to match the current DB's encoding.
Now, you'd have to work at it for that to cause problems --- say,
create such a situation in template0 and then copy template0 specifying
that other encoding. But none of that is forbidden.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-25 17:48:35 | Re: Is exec_simple_check_node still doing anything? |
Previous Message | Petr Jelinek | 2017-06-25 11:38:20 | Re: Walsender timeouts and large transactions |