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
-
Avoid conflicts with collation aliases generated by stripping.
- 0333a7340054 10.0 landed
-
Add function to import operating system collations
- aa17c06fb585 10.0 cited
-
Remove dead code in bootstrap
- 193a7d791ebe 10.0 cited