Re: collations in shared catalogs? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: collations in shared catalogs?
Date
Msg-id 24237.1431991439@sss.pgh.pa.us
Whole thread Raw
In response to Re: collations in shared catalogs?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: collations in shared catalogs?  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Run pgindent now?
Next
From: Andres Freund
Date:
Subject: Re: collations in shared catalogs?