Re: collations in shared catalogs?

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-02-25 20:53:48
Message-ID: 20150225205348.GB24199@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-02-25 12:08:32 -0500, Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-02-25 20:56:11 Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Previous Message Stephen Frost 2015-02-25 20:39:56 Re: CATUPDATE confusion?