Re: Database-Role settings behaviour and docs mismatch

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
plowahead anyway since we are    * trying to find out if the value is potentially good, not actually use    * it. Also
keepgoing if makeDefault is true, since we may want to set    * the reset/stacked values even if we can't set the
variableitself.    */   if (record->source > source)   {       if (changeVal && !makeDefault)       {
elog(DEBUG3,"\"%s\": setting ignored because previous source is higher priority",                name);
returntrue;       }       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