* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut <peter.eisentr...@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
signature.asc
Description: Digital signature