Skip site navigation (1) Skip section navigation (2)

Re: Database-Role settings behaviour and docs mismatch

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: (view raw, whole thread or download thread mbox)
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",
            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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-02-01 23:18:48
Subject: Re: Database-Role settings behaviour and docs mismatch
Previous:From: James William PyeDate: 2010-02-01 22:35:38
Subject: Re: plpython3

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group