Re: Per-database and per-user GUC settings - Mailing list pgsql-hackers

Peter Eisentraut <peter_e@gmx.net> writes:
> So basically, you have four useful combinations of these settings, which
> correspond to PGC_POSTMASTER, PGC_BACKEND, PGC_SIGHUP, and
> PGC_{SUSET,USERSET}.

Check.

> As for database-wide, I'm not sure how to interpret that.  Does that mean,
> this parameter must be the same for all concurrent sessions on the same
> database?  Is that something we ought to have?

Well, we haven't got it now, and I'm not sure whether there's anything
we'd really need it for.  I was speculating that we might want it for
something to do with schema paths or some such ... but it's hard to see
why those couldn't be treated as per-backend.  Certainly anything that
could be user-settable wouldn't be database-wide.

>> 2. From a security/privilege point of view, who should have the right to
>> change a given setting, and over what span of application?

> I don't see "database owner" as an independent concept:

Well, it is in terms of who gets to set the per-database GUC settings,
but I guess that doesn't directly relate to the privilege levels of the
individual settings.

> So basically, I think the current five levels of PGC_* should cover 1 and
> 2 OK.  Again, extensions are possible, but I don't see a need yet.

Okay, we can live with that for now, until/unless we see a reason to
invent a level that has something to do with per-database settings.

> OK, so what's the order:

> 1. run-time SET
> 2. per-user setting
> 3. per-database setting
> 4. backend options from client
> 5. postmaster command line
> 6. config file
> 7. wired-in default

Not sure; shouldn't backend options from client supersede the settings
taken from tables?  I'd be inclined to move up your #4 to between 1 and 2.
Otherwise this looks good.

> Meaning, any setting if provided can only take effect if the previous
> source of the setting had a higher number.

Same or higher number (to allow repeated SETs or config file changes).

> Another nice thing about this approach is that the current "bool
> makeDefault" parameter, which decides whether to save the new setting as
> default for RESET ALL, could be folded into "source > 1" (since
> everything except SET establishes a session default).

Right, I always felt that makeDefault was just a kluge to deal with one
of the deficiencies of the processing-order-sensitive implementation.

>> Okay, if it's agreed that standalone backends ignore these settings then
>> I think we can survive a screwup.

> Maybe there should be an option to turn this on or off, depending on what
> the default is.  Not sure yet.

That makes a lot of sense.  The standalone-backend environment is
already weird enough to make it mistake-prone; not loading your normal
settings would only make it more so.  I'd vote for having standalone
backends load your normal settings by default, but offer a command-line
switch to suppress that behavior; people would only use the switch if
their settings were too broken to load.
        regards, tom lane