From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: collations in shared catalogs? |
Date: | 2015-05-19 03:32:46 |
Message-ID: | 20150519033246.GK9584@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-05-18 23:22:33 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2015-05-18 19:59:29 -0400, Tom Lane wrote:
> >> I think that's fragile as can be.
>
> > Hm. I think actually just forcing a collation would bring this on-par
> > with name, right? We don't have any guarantees about the contents of
> > e.g. pg_database.datname being meaningful in another database with a
> > different encoding. In fact even the current database may have a name
> > that's in a wrong encoding.
>
> Oh, wait a minute. I just noticed that you have
> pg_replication_origin_roname_index defined to use varchar_pattern_ops.
> Now, this is mildly broken: it should be text_pattern_ops. But as far as
> I can see offhand, that eliminates the collation dependency for the index.
> The comparison rule is memcmp() which is not collation sensitive.
Hah. Right. Forgot about that. Oh Brain, where art thou.
> I'm inclined to think I should revert b82a7be603f1811a and instead make
> the seclabel provider columns use text_pattern_ops. That would fix
> their collation problem with less of a backwards compatibility hazard.
Sounds good to me. Are you doing that or should I?
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-05-19 03:34:16 | Re: a few thoughts on the schedule |
Previous Message | Tom Lane | 2015-05-19 03:30:20 | Re: a few thoughts on the schedule |