Re: pgsql: Add function to import operating system collations

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-committers <pgsql-committers@postgresql.org>
Date: 2017-01-19T16:54:07Z
Lists: pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > On 1/19/17 7:53 AM, Tom Lane wrote:
> >> Hm.  I see that the patch randomly changed the way that the collation
> >> owner is generated ... looks like it no longer works for mixed-case
> >> usernames.  Perhaps follow this model instead:
> 
> > We could just use the numeric value, like in the attached patch.
> 
> WFM.  Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10"
> in this bit in setup_privileges():
> 
> 		" (SELECT E'=r/\"$POSTGRES_SUPERUSERNAME\"' as acl "
> 		"  UNION SELECT unnest(pg_catalog.acldefault("
> 		"    CASE WHEN relkind = 'S' THEN 's' ELSE 'r' END::\"char\",10::oid))"
> 		" ) as a) "
> 
> Is there a reasonable way to fix that?  Maybe do another replace_token
> call for it?

Hm.  I seem to recall trying to avoid having the hard-coded value there
but we don't have BOOTSTRAP_SUPERUSERID defined somewhere that initdb.c
could include it from, do we?  It's only in catalog/pg_authid.h.

We could re-define it in initdb.c, of course, and perhaps that'd be
better than having it hard-coded.  I'm not sure that we really want to
expose BOOTSTRAP_SUPERUSERID to regular client code, or create some
additional set of headers which are just for initdb and the backend..

Of course, I might be missing something here, but I'm pretty sure that
was my thinking when I wrote that code.

Thanks!

Stephen

Commits

  1. Avoid conflicts with collation aliases generated by stripping.

  2. Add function to import operating system collations

  3. Remove dead code in bootstrap