[HACKERS] creating/accessing new runtime parameters

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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ

Re: [HACKERS] 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, Br

Re: [HACKERS] creating/accessing new runtime parameters

for the idea, though. Cheers, Brook ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] creating/accessing new runtime parameters

ying the behavior of interal functions. Cheers, Brook ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] psql as an execve(2) interpreter

r are there other portions of the code that need to be considered? I appreciate any feedback you can give me on this. Thank you very much. Cheers, Brook ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your des

Re: [HACKERS] psql as an execve(2) interpreter

cution with execve(2) figuring out which interpreter to use on a script-by-script basis. Currently, that is not possible, but it could be with a small modification to psql or the addition of a completely new interpreter. Thanks for the comments. Cheers, Brook ---(

Re: [HACKERS] psql as an execve(2) interpreter

behind those ideas. Cheers, Brook ---(end of broadcast)--- TIP 6: explain analyze is your friend

[HACKERS] handling contrib directories as modules not shared libraries

(,$(findstring contrib/,$(subdir))) shmodule = yes else shmodule = no Cheers, Brook -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] While we're on the subject of searches...

e. A well-thought out, coherent document is _much_ more useful than the skads of random tips that characterize some other projects. The current document is very well-written (though perhaps incomplete). I would hate to see that decline in quality. Cheers, Brook ---(end of

Re: [PATCHES] Re: [HACKERS] PostGIS spatial extensions

requisites mentioned above. Cheers, Brook --- [1] http://www.netbsd.org/Documentation/software/packages.html [2] ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/databases/README.html ---(end of

Re: [HACKERS] Using textin/textout vs. scribbling around

we cannot provide any external interface to the predefined types, then the well-known advantages of composing software modules from well-defined and well-tested components will be largely lost for anyone wishing to rapidly extend the system. Cheers, Brook ---(end of

[HACKERS] undocumented parts of SPI

t types of queries may be executed by a trigger using SPI_exec? Thanks for the help. Cheers, Brook

[HACKERS] type design guidance needed

right way to go about this, but I'm not sure where to look for alternatives. Thanks for your help. Cheers, Brook

Re: [HACKERS] type design guidance needed

nter. Adding a new system cache is a tad more invasive than the usual sort of user-defined-type addition, but it's certainly not out of the question. Bruce Momjian has done it several times and documented the process, IIRC. Bruce, is that the case? Do you really have it documented? If so, where? Cheers, Brook

Re: make depend (Re: [HACKERS] Coming attractions: VPATH build; make variables issue)

de in the tarball. For non-gmake users, all the *.d files already exist in the source. If they make changes, they can run make depend manually. Sorry if this is what you had in mind already, but the discussion seemed to imply that you can't have it both ways. Cheers, Brook