Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] 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 s

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Peter Eisentraut
[EMAIL PROTECTED] 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,

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread brook
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

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Joe Conway
Tom Lane wrote: <[EMAIL PROTECTED]> 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

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread brook
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 id

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Andreas Pflug
[EMAIL PROTECTED] 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 s

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Tom Lane
<[EMAIL PROTECTED]> 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

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread brook
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 ---

Re: [HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread Tom Lane
<[EMAIL PROTECTED]> 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,

[HACKERS] creating/accessing new runtime parameters

2003-09-24 Thread brook
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