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

TODO item: Allow more complex user/database default GUC settings

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: TODO item: Allow more complex user/database default GUC settings
Date: 2009-08-11 22:19:21
Message-ID: 20090811221921.GK16362@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

There's a longstanding TODO item, in subject.  Previous discussion was
here:

http://archives.postgresql.org/pgsql-hackers/2006-09/msg02341.php

In looking what it would take to implement it, I find that it is
trivial.  The only part that looks complex is the UI for it.  Is anyone
interested in giving this patch a shot?

Implementation-side, it requires a new catalog (pg_settings), with the
following columns:

setdatabase	oid
setrole		oid
setconfig	text[]

datconfig and rolconfig are removed.

ALTER DATABASE / SET sets setdatabase to the OID of the database in
command, and setrole to 0 (InvalidOid); ALTER ROLE / SET sets setrole
and leaves setdatabase 0.

A new command allows one to set a config that applies to both database
and role.

At startup, the settings are applied in the following order:
database=value	role=0
database=0	role=value
database=value	role=value

This way, current behavior is maintained (ALTER ROLE trumps ALTER
DATABASE).

The only real work in this is figuring out what the grammar for the new
command looks like.  Maybe we could have some like

ALTER ROLE foo ALTER DATABASE bar SET config

There are of course many possible variations but this looks the most
reasonable one.  Any better ideas?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-08-11 22:22:34
Subject: Re: [COMMITTERS] pgsql: Ship documentation without intermediate tarballs Documentation
Previous:From: Josh BerkusDate: 2009-08-11 22:06:54
Subject: Re: Why is vacuum_freeze_min_age 100m?

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