Re: collations in shared catalogs?
От | Andres Freund |
---|---|
Тема | Re: collations in shared catalogs? |
Дата | |
Msg-id | 20150519033246.GK9584@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: collations in shared catalogs? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: collations in shared catalogs?
|
Список | pgsql-hackers |
On 2015-05-18 23:22:33 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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?
В списке pgsql-hackers по дате отправления: