Re: [HACKERS] Making config file parser available to add-ins
Marc Munro wrote: I want Veil (http://pgfoundry.org/projects/veil/) to be able to read configuration details from a configuration file. What kind of details? By the time any server-side module is loaded, the configuration file has already been read, so why would you need to read it again? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Making config file parser available to add-ins
Peter Eisentraut [EMAIL PROTECTED] writes: Marc Munro wrote: I want Veil (http://pgfoundry.org/projects/veil/) to be able to read configuration details from a configuration file. What kind of details? By the time any server-side module is loaded, the configuration file has already been read, so why would you need to read it again? Probably the correct question is whether Marc's problem isn't already solved by the custom GUC variable mechanism --- that is, whatever he wants to configure should be defined as custom GUCs within the existing configuration file. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Making config file parser available to add-ins
Peter Eisentraut wrote: Marc Munro wrote: I want Veil (http://pgfoundry.org/projects/veil/) to be able to read configuration details from a configuration file. What kind of details? By the time any server-side module is loaded, the configuration file has already been read, so why would you need to read it again? We already have a mechanism to allow custom config sets in postgresql.conf. It's used by pl/java and pl/perl, for example. It probably needs better documentation. If you want to use another config file then your module probably should use its own parser. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making config file parser available to add-ins
On Mon, 2006-07-24 at 20:31 +0200, Peter Eisentraut wrote: Marc Munro wrote: I want Veil (http://pgfoundry.org/projects/veil/) to be able to read configuration details from a configuration file. What kind of details? By the time any server-side module is loaded, the configuration file has already been read, so why would you need to read it again? I want to read a veil config file rather than the postgres config file. Basically, I just want access to the rather nice config file parser that already exists. As for the kind of details: - how much shared memory to allocate for veil - the size of the hash tables for veil's shared variables __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Making config file parser available to add-ins
On Mon, 2006-07-24 at 14:44 -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Marc Munro wrote: I want Veil (http://pgfoundry.org/projects/veil/) to be able to read configuration details from a configuration file. What kind of details? By the time any server-side module is loaded, the configuration file has already been read, so why would you need to read it again? Probably the correct question is whether Marc's problem isn't already solved by the custom GUC variable mechanism --- that is, whatever he wants to configure should be defined as custom GUCs within the existing configuration file. I don't think it's already solved but I may be missing the point. The Veil shared library will be loaded by process_preload_libraries only after the postgresql config file has been read. I was assuming that at this point it would be too late to specify custom GUCs. Instead I want to load my own veil.conf file which would support the same sort of syntax as postgresql.conf. My proposal is to simply expose a new function processAddinConfigFile() which would mimic ProcessConfigFile but would call a user-supplied function to deal with each entry. Obviously, this would be usable by future add-ins and not just Veil. If there is a better way to do this please tell me. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Making config file parser available to add-ins
Marc Munro [EMAIL PROTECTED] writes: I don't think it's already solved but I may be missing the point. The Veil shared library will be loaded by process_preload_libraries only after the postgresql config file has been read. I was assuming that at this point it would be too late to specify custom GUCs. No, being able to do that is exactly the point of the custom-GUC mechanism. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Making config file parser available to add-ins
On Mon, 2006-07-24 at 15:17 -0400, Tom Lane wrote: No, being able to do that is exactly the point of the custom-GUC mechanism. Excellent. I shall study this and hope to bother you no further :-) Thanks. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Making config file parser available to add-ins
Marc Munro wrote: -- Start of PGP signed section. On Mon, 2006-07-24 at 15:17 -0400, Tom Lane wrote: No, being able to do that is exactly the point of the custom-GUC mechanism. Excellent. I shall study this and hope to bother you no further :-) And in 8.2, postgresql.conf can include other configuration files. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
