I wrote: > ... So we could solve both this and > the original complaint in the thread if we can arrange for all > authentication to be done on the basis of shared-catalog access under > rules similar to what the AV launcher does with pg_database. At a > minimum that will require marking the pg_auth catalogs as > BKI_SCHEMA_MACRO, but that's far less painful than it used to be. > I don't recall what other consequences there are, but will go looking.
I've been looking at this and it seems do-able, though I don't have working code yet. Downsides appear to be: 1. We'd have to force an initdb because of a couple of small catalog changes. This doesn't seem like a showstopper at this phase of the release cycle, but it's slightly annoying. pg_migrator could be used if anyone's really in need of it. 2. We don't have infrastructure that would allow access to out-of-line toasted fields during startup. Rather than try to add such, I propose removing pg_authid's toast table, with the consequence that rolpassword cannot be long enough to require out-of-line storage (note it could still be compressed in-line). I cannot imagine any real situation where this would be an issue --- does anyone else? (BTW, I'm fairly sure that we couldn't support an out-of-line rolpassword in the past anyway, because of restrictions in the old flatfiles code.) 3. We'd have to nail pg_authid, pg_auth_members, and their indexes into relcache, because relcache.c isn't prepared to cope otherwise. I doubt this would affect performance in any material way, but it would eat a few more kbytes of storage per backend. None of these seem like reasons not to do it. Objections? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers