Simon Riggs wrote: > Whereas in process_settings() the sequence is this > > ApplySetting(databaseid, roleid, relsetting, PGC_S_DATABASE_USER); > ApplySetting(InvalidOid, roleid, relsetting, PGC_S_USER); > ApplySetting(databaseid, InvalidOid, relsetting, PGC_S_DATABASE); > > which looks to me like database-role specific settings are overridden by > both user and database specific ones, in contrast to how the docs > describe this.
Yeah, except that set_config_option contains this bit: /* * Ignore attempted set if overridden by previously processed setting. * However, if changeVal is false then plow ahead anyway since we are * trying to find out if the value is potentially good, not actually use * it. Also keep going if makeDefault is true, since we may want to set * the reset/stacked values even if we can't set the variable itself. */ if (record->source > source) { if (changeVal && !makeDefault) { elog(DEBUG3, "\"%s\": setting ignored because previous source is higher priority", name); return true; } changeVal = false; } > Not that bothered, but seems like the docs provide more useful behaviour > and the code less useful. It'd probably be worth changing the order of the ApplySetting calls so that it doesn't look suspicious. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers