[HACKERS] CREATE COLLATION definitional questions for ICU
От | Tom Lane |
---|---|
Тема | [HACKERS] CREATE COLLATION definitional questions for ICU |
Дата | |
Msg-id | 10962.1498405528@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] CREATE COLLATION definitional questions for ICU
Re: [HACKERS] CREATE COLLATION definitional questions for ICU Re: [HACKERS] CREATE COLLATION definitional questions for ICU Re: [HACKERS] CREATE COLLATION definitional questions for ICU |
Список | 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
В списке pgsql-hackers по дате отправления: