From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Database-Role settings behaviour and docs mismatch |
Date: | 2010-02-01 23:11:43 |
Message-ID: | 20100201231143.GD7363@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-02-01 23:18:48 | Re: Database-Role settings behaviour and docs mismatch |
Previous Message | James William Pye | 2010-02-01 22:35:38 | Re: plpython3 |