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

user defined settings (aka user defined guc variables)

From: Joe Conway <mail(at)joeconway(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: user defined settings (aka user defined guc variables)
Date: 2002-12-19 01:00:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I've been playing around with making it possible to create user defined guc 
variables. This has been discussed, at least in passing, before. And it is 
even anticipated in guc.c as a possible future feature:
  * Build the sorted array.	This is split out so that it could be
  * re-executed after startup (eg, we could allow loadable modules to
  * add vars, and then we'd need to re-sort).

It is a feature that would be nice to have, so that, for example, a user 
defined variable named "my_classpath" could be created to point to the java 
CLASSPATH needed by a custom C function.

So far I have this much working:
- A new backend function, pg_create_user_setting(name, value, islocal) is used
   to "register" the setting.
- SHOW ALL, SHOW, current_setting(), and pg_show_all_settings()) will display
   it just like any other setting
- Similarly, SET and set_config() will change it.

I still need to make the user defined settings survive being saved by ALTER 
USER or ALTER DATABASE. I'm also thinking about a corresponding grammar 
addition, something along the lines of:


This would effectively perform:
   SELECT pg_create_user_setting(name, value, false);

I'm wondering whether it would be "a good thing" or "a bad thing" to have 
unrecognized settings found in postgresql.conf be registered as user defined 

Any comments, concerns, or objections?




pgsql-hackers by date

Next:From: Tom LaneDate: 2002-12-19 01:07:52
Subject: Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal: array utility functions phase 1)]
Previous:From: Joe ConwayDate: 2002-12-19 00:20:31
Subject: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal: array utility functions phase 1)]

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