Peter Eisentraut writes:
> On 6/25/17 11:45, Tom Lane wrote:
>> * 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
On 6/27/17 11:17, Tom Lane wrote:
> Moreover, if you insist on defining it this way, it's going to limit
> our freedom of action in future. It's possible that, either in some
> future version of ICU or for some other provider, there could be more
> than one version of a collation simultaneously
On 6/25/17 11:45, Tom Lane wrote:
> * 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
On 6/25/17 11:45, Tom Lane wrote:
> * 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?
I have fixed that for now by enforcing them to be the same.
In the longer term, I'm thinking about converting these two
On 6/25/17 11:45, Tom Lane wrote:
> * 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.
Peter Eisentraut writes:
> On 6/25/17 11:45, Tom Lane wrote:
>> * 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.
> I think this is
On 6/25/17 11:45, Tom Lane wrote:
> * 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.
I think this is working correctly. Specifying the version explicitly is
really only