Re: collations in shared catalogs?
От | Tom Lane |
---|---|
Тема | Re: collations in shared catalogs? |
Дата | |
Msg-id | 24237.1431991439@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: collations in shared catalogs? (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: collations in shared catalogs?
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2015-02-25 12:08:32 -0500, Tom Lane wrote: >> Andrew Gierth <andrew@tao11.riddles.org.uk> writes: >>> So while helping someone with an unrelated issue, I did a quick query to >>> look for collation-dependent indexes, and was rather shocked to find >>> that not only are there two such in the system catalogs, both set to >>> "default" collation, but that one of them is in a _shared_ catalog >>> (pg_shseclabel). >>> How did that happen? And how could it possibly work? >> It probably doesn't, and the reason nobody has noticed is that the >> security label stuff has fewer users than I have fingers (and those >> people aren't using provider names that would cause anything interesting >> to happen). >> >> The most obvious fix is to change "provider" to a NAME column. > Yea. I'm not sure why that wasn't done initially. OK, now I'm on the warpath, because I went to fix this and discovered that since that discussion, somebody named Freund committed yet another shared catalog with a collation-dependent index. This time, at least, we can fix it *before* it gets into the wild. Is it okay to change pg_replication_origin.roname to type "name", and if not what do you want to do instead? While I'm looking at it, why in the world have roident and not just a standard system OID column? This catalog seems willfully ignorant of Postgres conventions. regards, tom lane
В списке pgsql-hackers по дате отправления: