Thread: creating/accessing new runtime parameters
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
<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
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
<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
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
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
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
Joe Conway writes:> I had a patch about 80% complete to do this, but it was rejected. The > comment was that I should usea 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
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
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