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

From Andres Freund
Subject Re: collations in shared catalogs?
Date
Msg-id 20150225205348.GB24199@awork2.anarazel.de
Whole thread Raw
In response to Re: collations in shared catalogs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: collations in shared catalogs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: collations in shared catalogs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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. I can't really see the
length be an issue. How about we add an error check enforcing ascii,
that'll work in the back branches?

Generally it's not the greatest idea to have non-ascii stuff in shared
catalogs...

> What was the other case?  We might want to add a regression test to
> check for collation-dependent system indexes ...

+1

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: CATUPDATE confusion?
Next
From: Tomas Vondra
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)