I am writing a backend C function whose behavior should depend on the
setting of a new runtime parameter that can be set with SET.  I have
several questions concerning how to implement this, as I can find no
information in the documentation.

- How can I introduce a new variable (e.g., XXX) to the system so that
  for example SET XXX=1 will work?

- How can I access the value of such a variable from within a backend
  C function?

Thanks for your help.

Cheers,
Brook

Wed, 24 Sep 2003 07:49:33 -0600
<brook@biology.nmsu.edu>
creating/accessing new runtime parameters
<brook@biology.nmsu.edu> writes:
> - How can I introduce a new variable (e.g., XXX) to the system so that
>   for example SET XXX=1 will work?

The basic thing is to add an appropriate table entry to guc.c.  You
might try searching the sources for all references to one of the
lesser-used GUC variables, perhaps default_statistics_target, to get
a feeling for what's involved.

			regards, tom lane

Wed, 24 Sep 2003 10:45:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: creating/accessing new runtime parameters 
Tom Lane writes:
 > The basic thing is to add an appropriate table entry to guc.c.

I take it there is not way to do this dynamically, for example to
support a dynamically loaded function?  All runtime variables are
hard-coded into the backend?

Thanks for your help.

Cheers,
Brook

Wed, 24 Sep 2003 09:50:37 -0600
<brook@biology.nmsu.edu>
Re: creating/accessing new runtime parameters 
<brook@biology.nmsu.edu> writes:
> Tom Lane writes:
>>> The basic thing is to add an appropriate table entry to guc.c.

> I take it there is not way to do this dynamically, for example to
> support a dynamically loaded function?

Not at the moment, although IIRC the guc.c data structures are designed
to make it possible to add things on-the-fly.  (There's a pointer table
that's built dynamically, and in theory could contain more entries than
are in the hardcoded tables.)  You'd need to add a routine to actually
add an entry ... and figure out where to call it from ...

			regards, tom lane

Wed, 24 Sep 2003 11:57:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: creating/accessing new runtime parameters 
brook@biology.nmsu.edu wrote:

>Tom Lane writes:
> > The basic thing is to add an appropriate table entry to guc.c.
>
>I take it there is not way to do this dynamically, for example to
>support a dynamically loaded function?  All runtime variables are
>hard-coded into the backend?
>
Maybe you can implement your stuff using a temporary table?

Regards,
Andreas



Wed, 24 Sep 2003 18:04:12 +0200
Andreas Pflug <pgadmin@pse-consulting.de>
Re: creating/accessing new runtime parameters
Andreas Pflug writes:
 > Maybe you can implement your stuff using a temporary table?

Perhaps, but the runtime variable route is much more natural from a
user interface perspective, as there are strong parallels with
existing variables.  I'll see what I can do in that arena first.
Thanks for the idea, though.

Cheers,
Brook

Wed, 24 Sep 2003 10:14:21 -0600
<brook@biology.nmsu.edu>
Re: creating/accessing new runtime parameters
Tom Lane wrote:
> <brook@biology.nmsu.edu> writes:
>>I take it there is not way to do this dynamically, for example to
>>support a dynamically loaded function?
> 
> Not at the moment, although IIRC the guc.c data structures are designed
> to make it possible to add things on-the-fly.  (There's a pointer table
> that's built dynamically, and in theory could contain more entries than
> are in the hardcoded tables.)  You'd need to add a routine to actually
> add an entry ... and figure out where to call it from ...
> 

I had a patch about 80% complete to do this, but it was rejected. The 
comment was that I should use a temp table instead. I still think it 
would be useful myself. See this thread:

http://archives.postgresql.org/pgsql-hackers/2002-12/msg00988.php

Joe


Wed, 24 Sep 2003 09:21:23 -0700
Joe Conway <mail@joeconway.com>
Re: creating/accessing new runtime parameters
Joe Conway writes:
 > I had a patch about 80% complete to do this, but it was rejected. The 
 > comment was that I should use a temp table instead. I still think it 
 > would be useful myself. See this thread:
 > 
 > http://archives.postgresql.org/pgsql-hackers/2002-12/msg00988.php

I'm sorry that was rejected.  I can see that there might be error
checking issues, but perhaps that simply means some hooks to register
validation functions dynamically that could be called during SET.

As far as the general utility of it goes, I claim that it could be
quite valuable.  I am thinking of complex new datatypes (that might be
dynamically loaded) that could benefit from having some run-time
variables specify some aspect of their behavior.  Currently, we have
variables controlling the I/O of dates and times, for example.
Something analogous would potentially be useful for other datatypes.
Without the ability to dynamically add to the set of run-time
variables, it is impossible to write a datatype that has this
property.

In these cases, one really does want run-time variables, not temporary
tables, as the use exactly corresponds to the use for existing
variables:  modifying the behavior of interal functions.

Cheers,
Brook

Wed, 24 Sep 2003 14:02:17 -0600
<brook@biology.nmsu.edu>
Re: creating/accessing new runtime parameters
brook@biology.nmsu.edu writes:

> As far as the general utility of it goes, I claim that it could be
> quite valuable.  I am thinking of complex new datatypes (that might be
> dynamically loaded) that could benefit from having some run-time
> variables specify some aspect of their behavior.  Currently, we have
> variables controlling the I/O of dates and times, for example.
> Something analogous would potentially be useful for other datatypes.

Consider it an encouragement to have your data types not duplicate any of
the various insane properties that date/time types have, imposed by the
real world.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 24 Sep 2003 23:14:17 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: creating/accessing new runtime parameters
Peter Eisentraut <peter_e@gmx.net> writes:
> brook@biology.nmsu.edu writes:
>> As far as the general utility of it goes, I claim that it could be
>> quite valuable.  I am thinking of complex new datatypes (that might be
>> dynamically loaded) that could benefit from having some run-time
>> variables specify some aspect of their behavior.  Currently, we have
>> variables controlling the I/O of dates and times, for example.
>> Something analogous would potentially be useful for other datatypes.

> Consider it an encouragement to have your data types not duplicate any of
> the various insane properties that date/time types have, imposed by the
> real world.

Unfortunately, real-world requirements impinge upon most things ;-)
I'm somewhat persuaded by Brook's argument.

The original discussion didn't really reject the idea of allowing
addition of new GUC variables; the concerns were about how and when
to do that.  We didn't like Joe's suggestion of registering any random
name that happens to appear in postgresql.conf (no error checking, and
besides how would you deduce the type and other properties?).  However,
it seems like you *would* like added-on names to be settable from
postgresql.conf, so just allowing dynamically loaded modules to add them
when first invoked by a backend would be very limiting.

Now that we have the notion of postmaster-preloaded dynamic libraries,
I was thinking maybe we could let those libraries define new GUC variables.
Right now, preload_libraries doesn't get processed until after we've
scanned guc.c, but maybe that could be rethought.  Could we preload a
library at the instant we see the preload_library setting in guc.c,
allowing it to define GUC vars that will be recognized later in the
file?

There are probably other ways we could attack it, too, but that was the
first thing that came to mind.

			regards, tom lane

Wed, 24 Sep 2003 17:51:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: creating/accessing new runtime parameters 