* 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
