Re: [HACKERS] postgres --help-config
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I like --dump-config. Better to have the verb first. My only objection to that is that dump suggests you will get some kind of snapshot of current settings, which is not what this facility does. I think people will associate dump with pg_dump, meaning dump out the data. I don't think the snapshot idea will not occur to them. Copy has an in/out capability that doesn't match. --display-config might have the more accurate meaning you were looking for. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I like --dump-config. Better to have the verb first. My only objection to that is that dump suggests you will get some kind of snapshot of current settings, which is not what this facility does. I don't have an especially good alternative though ... --describe-config is the only thought that comes to mind right away. I just realized that --help-config doesn't output the contents of postgresql.conf at all, but just the internal server defaults. Does the admin tool read postgresql.conf too and parse that to get the runtime values, and how does it know if the postmaster is using the current postgresql.conf contents or it needs a SIGHUP? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: I just realized that --help-config doesn't output the contents of postgresql.conf at all, but just the internal server defaults. Does the admin tool read postgresql.conf too and parse that to get the runtime values, and how does it know if the postmaster is using the current postgresql.conf contents or it needs a SIGHUP? The tool is using the output to help people create postgresql.conf. The postmaster isn't running. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] postgres --help-config
Tom Lane writes: The tool is using the output to help people create postgresql.conf. The postmaster isn't running. But how do you alter postgresql.conf it it already exists but you don't know the current values? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] postgres --help-config
Tom Lane writes: I don't have an especially good alternative though ... --describe-config is the only thought that comes to mind right away. I like that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] postgres --help-config
Tom Lane writes: I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. True. 2) Make real separate short and long descriptions. We'd have to break the strings freeze to do that. How bad do you want it? I like the first option. But we'll have to break the string freeze either way. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: The tool is using the output to help people create postgresql.conf. The postmaster isn't running. But how do you alter postgresql.conf it it already exists but you don't know the current values? You read postgresql.conf to extract the non-comment lines, and overlay those on the default values you got from --help-config. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. True. I like the first option. But we'll have to break the string freeze either way. Fernando pointed out to me that the separate-fields approach does help make it obvious that the first sentence of the description has special status and needs to be able to stand on its own. If we merge the descriptions into one field, it'll be easier to make the kind of mistake I made with check_function_bodies. So I'm back to the opinion that the current setup is not broken, other than that the fields are misleadingly named, which we could fix easily. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Bruce Momjian writes: The problem is how that affects Red Hat. What do they do with their tool? They could use the prototype version of this feature that implemented a separate program (pg_guc) that provided this information. That way they can generate any output they want for as long as they want without affecting anyone. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres --help-config
Tom Lane writes: It'd be better if we could get it right the first time, with the understanding that the output format is not very negotiable at this late hour. But as best I can tell, most of the unhappiness is with the design of the switch set, which is not something I want to defend in detail. There's a lot there that isn't needed for the RHDB tool as I understand it, and I think that altering the switches used to get the output that the tool does need would still be a feasible change from the tool's point of view. I have some more questions: - When the set of GUC properties (when to set, how to set, etc.) change, what is the upgrade path? Remember that we change those a lot. - Who is going to maintain the descriptions in this very special GNU trick format? I can happily agree if we had a short description that is shown in an overview list, and an long description that is shown when the option is opened up in its own window, but I don't agree with with the current format. At least not in the way it was explained to me, maybe I'm misunderstanding. I would be in favor of simplifying the supported switch set to the minimum needed by Red Hat's tool (the equivalent of -G -M if I understood Fernando correctly), and re-adding complexity in future when and if it's shown to be needed. But we need to make a decision about this now. Preferably yesterday. I propose we rip out everything except --help-config -m that shows the information in the machine-readable tab separated format without headers. If someone can answer the two questions above. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: 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] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: ... Will Red Hat be upset if we leave it unchanged for 7.4.X and rip this out and redo it in 7.5? It'd be better if we could get it right the first time, with the understanding that the output format is not very negotiable at this late hour. But as best I can tell, most of the unhappiness is with the design of the switch set, which is not something I want to defend in detail. There's a lot there that isn't needed for the RHDB tool as I understand it, and I think that altering the switches used to get the output that the tool does need would still be a feasible change from the tool's point of view. I would be in favor of simplifying the supported switch set to the minimum needed by Red Hat's tool (the equivalent of -G -M if I understood Fernando correctly), and re-adding complexity in future when and if it's shown to be needed. But we need to make a decision about this now. Preferably yesterday. I understand we want to get something that _isn't_ going to change after 7.4. That's why I proposed a simple --help-config in user-readable format (might be improved in the future), and a --help-config-raw in tab format, without headers. Seems the tool can use the tab format to do whatever it wants, including loading it into a C structure and running the existing help_config.c code over it. I also can't imagine the raw format every changing, because of course, it is raw. I think everyone agrees we need a user-readable and machine-readable output for this. As I mentioned earlier, SRA has a tool that does this too, so it must be a pretty common need. My guess is that every tool is going to want to get at the data in a different way, so we are better off just passing the data in a neutral format and letting the tool manipulate the data, rather than trying to guess what features the tool will need. One thing that seems very strange about the current API are flags that have meaning only when --help-config becomes before it, as with -G and -M. I have never seen that before, and I don't know how we would even document that. We do have pg_ctl that has different flags for different modes, but a word is required at the beginning, not a flag. I guess iff someone needs raw with headers in the future, I guess we could add --help-config-raw-headers. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Peter Eisentraut wrote: Tom Lane writes: It'd be better if we could get it right the first time, with the understanding that the output format is not very negotiable at this late hour. But as best I can tell, most of the unhappiness is with the design of the switch set, which is not something I want to defend in detail. There's a lot there that isn't needed for the RHDB tool as I understand it, and I think that altering the switches used to get the output that the tool does need would still be a feasible change from the tool's point of view. I have some more questions: - When the set of GUC properties (when to set, how to set, etc.) change, what is the upgrade path? Remember that we change those a lot. You mean when we add another member the GUC structure? I assume the tool is first going to have to test for the PostgreSQL version, and handle each version slightly differently --- I don't see another way. Perhaps that's what the 'headings' flag was for, but I don't think that really helps much --- there has to be code to understand what that new column means. - Who is going to maintain the descriptions in this very special GNU trick format? I can happily agree if we had a short description that is shown in an overview list, and an long description that is shown when the option is opened up in its own window, but I don't agree with with the current format. At least not in the way it was explained to me, maybe I'm misunderstanding. Are you talking about the descriptions in the guc.c file that are part of the GUC structures? I think we are heading in a direction where we should be pulling descriptions out of SGML like we do with psql help, and using that to load the GUC structures with descriptions. I don't see another long-term solution, do you? I would be in favor of simplifying the supported switch set to the minimum needed by Red Hat's tool (the equivalent of -G -M if I understood Fernando correctly), and re-adding complexity in future when and if it's shown to be needed. But we need to make a decision about this now. Preferably yesterday. I propose we rip out everything except --help-config -m that shows the information in the machine-readable tab separated format without headers. If someone can answer the two questions above. I just proposed that as --help-config-raw. I don't think we want to head in the direction of having flags like -m be useful only if preceeded by a --help-config flag --- it is too confusing. I think --help-config and --help-config-raw is all we will ever need. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: ... Will Red Hat be upset if we leave it unchanged for 7.4.X and rip this out and redo it in 7.5? It'd be better if we could get it right the first time, with the understanding that the output format is not very negotiable at this late hour. But as best I can tell, most of the unhappiness is with the design of the switch set, which is not something I want to defend in detail. There's a lot there that isn't needed for the RHDB tool as I understand it, and I think that altering the switches used to get the output that the tool does need would still be a feasible change from the tool's point of view. I would be in favor of simplifying the supported switch set to the minimum needed by Red Hat's tool (the equivalent of -G -M if I understood Fernando correctly), and re-adding complexity in future when and if it's shown to be needed. But we need to make a decision about this now. Preferably yesterday. Oh, the raw output format should follow the COPY format output, meaning literal newlines are \n and literal tabs are \tab, and double literal backslash. I am mentioning this now so we will not have to modify this output format in the future in case we need literal tab/newlines. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] postgres --help-config
Bruce Momjian wrote: I propose we rip out everything except --help-config -m that shows the information in the machine-readable tab separated format without headers. If someone can answer the two questions above. I just proposed that as --help-config-raw. I don't think we want to head in the direction of having flags like -m be useful only if preceeded by a --help-config flag --- it is too confusing. I think --help-config and --help-config-raw is all we will ever need. Or you could allow --help-config to take an optional argument of raw. I agree that having flag interdependencies like the original is confusing. Just a thought. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: One thing that seems very strange about the current API are flags that have meaning only when --help-config becomes before it, as with -G and -M. I have never seen that before, postgres -boot does exactly that, and the new code was modeled on it. Which doesn't make it good design, maybe, but you can hardly claim that there's no precedent. We had also considered choosing a different executable name (the postmaster-vs-postgres trick). But on platforms without symlinks, like Windows, that would mean an extra whole copy of the backend in the installed system, which seemed a bit much just to avoid some ugliness in the switch set... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: I understand we want to get something that _isn't_ going to change after 7.4. That's why I proposed a simple --help-config in user-readable format (might be improved in the future), and a --help-config-raw in tab format, without headers. Actually, I think the point Peter's been making is that it's not clear we need a user-readable output format at all. The variant you are calling --help-config-raw is the only one that needs to be supported in 7.4, and anything else should (arguably) be left off so that it doesn't constrain a future redesign. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: - When the set of GUC properties (when to set, how to set, etc.) change, what is the upgrade path? Remember that we change those a lot. Well, when we add another PGC_ category, that will mean another possible output value in the column representing same. That doesn't bother me particularly. The other flag bits that we have aren't currently reflected in the help-config output at all, so changing them doesn't affect it. - Who is going to maintain the descriptions in this very special GNU trick format? What's special about it? I now understand that I'd misdescribed it, and that the fields ought to be named something like desc and extra_desc rather than short_desc and long_desc. But I don't see anything wrong with the concept. The short description is also the first sentence of the long description; what's unreasonable about that? I propose we rip out everything except --help-config -m that shows the information in the machine-readable tab separated format without headers. If someone can answer the two questions above. Actually I think -M -G corresponds to that set of choices. Are we converging on an agreement that we only need that functionality for now? If so, what switch shall be used to get it? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Actually, I think the point Peter's been making is that it's not clear we need a user-readable output format at all. The variant you are calling --help-config-raw is the only one that needs to be supported in 7.4, and anything else should (arguably) be left off so that it doesn't constrain a future redesign. I agree. We can revive the pg_guc utility to obtain the raw input using 'postgres --help-config' and format it the way you want and give it all the switches that people may want. I just wonder if having a help-like option without human-readable output is OK. We can always document that it is for machine consumption, of course. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres --help-config
Bruce Momjian wrote: (...) I guess iff someone needs raw with headers in the future, I guess we could add --help-config-raw-headers. I don't mind if you make it always with the headers. We can easily strip the first line when reading the file and people can easily strip it piping the output through a filter before sorting it etc. I am thinking that the headers would allow a output formatting utility to do it in a way that is independent of the version, and avoid having to run pg_config --version as well. As the values are all strings it can blindly create a column for every header. The only fields that the program need to know about (like name and group) are not likely to change. No big deal though. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: Are you talking about the descriptions in the guc.c file that are part of the GUC structures? I think we are heading in a direction where we should be pulling descriptions out of SGML like we do with psql help, and using that to load the GUC structures with descriptions. Peter had suggested generating the docs and the GUC table from a common source file, and I think that is the way to go, but it's obviously not getting done for 7.4. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I understand we want to get something that _isn't_ going to change after 7.4. That's why I proposed a simple --help-config in user-readable format (might be improved in the future), and a --help-config-raw in tab format, without headers. Actually, I think the point Peter's been making is that it's not clear we need a user-readable output format at all. The variant you are calling --help-config-raw is the only one that needs to be supported in 7.4, and anything else should (arguably) be left off so that it doesn't constrain a future redesign. Agreed. No one is asking for user-readable output, and if we output in COPY format, we can just publish the schema and they can load it into their favorate database. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: One thing that seems very strange about the current API are flags that have meaning only when --help-config becomes before it, as with -G and -M. I have never seen that before, postgres -boot does exactly that, and the new code was modeled on it. Which doesn't make it good design, maybe, but you can hardly claim that there's no precedent. However, -boot isn't documented because it is only for internal use. If it was for general use, I doubt it would still use that API. We had also considered choosing a different executable name (the postmaster-vs-postgres trick). But on platforms without symlinks, like Windows, that would mean an extra whole copy of the backend in the installed system, which seemed a bit much just to avoid some ugliness in the switch set... Agreed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] postgres --help-config
Fernando Nasser wrote: Bruce Momjian wrote: (...) I guess iff someone needs raw with headers in the future, I guess we could add --help-config-raw-headers. I don't mind if you make it always with the headers. We can easily strip the first line when reading the file and people can easily strip it piping the output through a filter before sorting it etc. I think we are better off without headers. COPY doesn't have headers, so if we are using COPY output format, headers don't make sense --- any my guess is that you will have to check --version anyway for special handling, so having the headings isn't going to be a huge help. If we want headings, I suggest we have a special option that dumps out _only_ the headings. In fact, it might be nicer to have it dump out the CREATE TABLE needed to load the raw output. I am thinking that the headers would allow a output formatting utility to do it in a way that is independent of the version, and avoid having to run pg_config --version as well. As the values are all strings it can blindly create a column for every header. The only fields that the program need to know about (like name and group) are not likely to change. At this point, we should probably just do what is needed, and revisit for 7.5 --- straight COPY output would probably do the trick. Now, for a name. I wonder if --config-copy would be OK. It documents it is in COPY output format, and it allows us to add a human-readable version in the future if we ever want one. I didn't like --help-config because it is too easily confused with --help, which documents command-line flags --- this really doesn't do that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] postgres --help-config
Bruce Momjian wrote: At this point, we should probably just do what is needed, and revisit for 7.5 --- straight COPY output would probably do the trick. Now, for a name. I wonder if --config-copy would be OK. It documents it is in COPY output format, and it allows us to add a human-readable version in the future if we ever want one. I didn't like --help-config because it is too easily confused with --help, which documents command-line flags --- this really doesn't do that. I am now thinking maybe --config-dump would be the proper option name --- it is really a dump of the config stuff. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
Tom Lane writes: - Who is going to maintain the descriptions in this very special GNU trick format? What's special about it? I now understand that I'd misdescribed it, and that the fields ought to be named something like desc and extra_desc rather than short_desc and long_desc. But I don't see anything wrong with the concept. The short description is also the first sentence of the long description; what's unreasonable about that? It constrains the writer of the description in a way he might not suspect. For example, we have check_function_bodies (boolean) This parameter is normally true. When set false, it disables validation ... Then the primary description would become This parameter is normally true. I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. 2) Make real separate short and long descriptions. I propose we rip out everything except --help-config -m that shows the information in the machine-readable tab separated format without headers. If someone can answer the two questions above. Actually I think -M -G corresponds to that set of choices. Are we converging on an agreement that we only need that functionality for now? If so, what switch shall be used to get it? I'm thinking that a completely different option name like --dump-config or --copy-config-info is better than something that implies help. I would actually like --help-config to work exactly like --help, so it displays something like Options: ... --sort-mem=INTamount of memory to be used by internal sort operations and hash tables before switching to temporary disk files --... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] postgres --help-config
Peter Eisentraut wrote: Actually I think -M -G corresponds to that set of choices. Are we converging on an agreement that we only need that functionality for now? If so, what switch shall be used to get it? I'm thinking that a completely different option name like --dump-config or --copy-config-info is better than something that implies help. I would actually like --help-config to work exactly like --help, so it displays something like Options: ... --sort-mem=INTamount of memory to be used by internal sort operations and hash tables before switching to temporary disk files --... Agreed. I like --dump-config. Better to have the verb first. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: Agreed. I like --dump-config. Better to have the verb first. My only objection to that is that dump suggests you will get some kind of snapshot of current settings, which is not what this facility does. I don't have an especially good alternative though ... --describe-config is the only thought that comes to mind right away. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres --help-config
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: But I don't see anything wrong with the concept. The short description is also the first sentence of the long description; what's unreasonable about that? It constrains the writer of the description in a way he might not suspect. For example, we have check_function_bodies (boolean) This parameter is normally true. When set false, it disables validation ... Then the primary description would become This parameter is normally true. You have a point, but on the other hand, as the author of that particular description I can feel free to criticize it. It's generally considered good style for the first sentence of a paragraph to convey the basic point. (In fact, I recall being dissatisfied with that text when I wrote it, but I was too rushed to fix it.) Maybe we should just go ahead and rewrite the variable descriptions to conform to this style. I think there are two ways this can be resolved: 1) Leave it this way, deal with it, but then we can put everything in one field and let the software parse out the first sentence automatically. True. 2) Make real separate short and long descriptions. We'd have to break the strings freeze to do that. How bad do you want it? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] postgres --help-config
On Wed, Oct 15, 2003 at 07:22:56PM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: 2) Make real separate short and long descriptions. We'd have to break the strings freeze to do that. How bad do you want it? It doesn't take a lot to re-translate, IMO as a translator. It's just a dozen or two of strings, isn't it? The backend has some 1800 messages, several of which are a lot longer and more difficult to translate. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La naturaleza, tan frágil, tan expuesta a la muerte... y tan viva ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
On Tue, Oct 14, 2003 at 11:34:14AM -0400, Fernando Nasser wrote: Unrelated question, And we developed a very nice tool that depends on this feature confident that we could count on it. Is this tool going to be released somehow? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) I dream about dreams about dreams, sang the nightingale under the pale moon (Sandman) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres --help-config
Alvaro Herrera [EMAIL PROTECTED] writes: On Tue, Oct 14, 2003 at 11:34:14AM -0400, Fernando Nasser wrote: And we developed a very nice tool that depends on this feature confident that we could count on it. Is this tool going to be released somehow? Certainly. Keep an eye on http://sources.redhat.com/rhdb/ I'm not sure what the release schedule is for that particular tool, but it's soon. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
Fernando Nasser wrote: Bruce, Before I comment on your suggestions, I would like to mention that many of the things below were added on request by the few people who cared to comment on it. Aizaz spent most of his time changing here and there to accommodate these requests. Anyway, we know we can't satisfy all, but I wish people would be more timely when criticizing things. Aizaz is away until May and left thinking everything was under control. And we developed a very nice tool that depends on this feature confident that we could count on it. I understand this is not ideal timing. However, open source is certainly very fluid and it is hard when someone adds something and then isn't available for later adjustments. I knew you were adding --help-config, but I didn't realize the extent of the features. The commit message is: revision 1.1 date: 2003/07/04 16:41:21; author: tgl; state: Exp; Add --help-config facility to dump information about GUC parameters without needing a running backend. Reorder postgresql.conf.sample to match new layout of runtime.sgml. This commit re-adds work lost in Wednesday's crash. which I thought was a single option, which we all knew was needed, not six additional options for output format. Also, with no documention, or a posted list of the flags you wanted to add (at least I never saw it), it was easy to miss. Imagine SRA wanted some features added to work better with their admin tool --- if all the companies did that, PostgreSQL could become a bloated mess. Bruce Momjian wrote: Tom Lane wrote: First, the default output should have the sorted field first. It appears the default is to sort by context: postgres --help-config That should be the first printed field. However, I see you can sort by Group, so maybe group should always be first --- that seems most logical. Whatever you do to the human-readable output, please don't change the -M/-m format. It makes it harder to write code to parse these things if the fields keep changing positions. Someone is supposed to write an utility to create the sample postgresql.conf file from the output as well. I believe this tool would use it without the -G so that is why we have the -G option. Also, it was deemed better for the user readable output to have it grouped (it is easier to check with the documentation as well when it is being reviewed). We don't normally add things until someone is ready to do the actual coding --- only then do we know what they will really want. The documentation I see is the command-line help in the C file: printf(gettext(Usage:\n %s --help-config [OPTION]... [NAME]\n\n), progname); printf(gettext(General Options:\n)); printf(gettext( NAME output information about parameters matching this name\n)); printf(gettext( -g GROUP output information about parameters matching this group\n)); printf(gettext( -llist available parameter groups\n)); printf(gettext( -hshow this help, then exit\n)); We don't use the ones above. printf(gettext(\nOutput Options:\n)); printf(gettext( -G do not group by category\n)); printf(gettext( -m machine-friendly format: tab separated fields\n)); printf(gettext( -M same as -m, but header with column names is suppressed\n)); We do use these. I don't see any value to most of these parameters, and the add them in case they might need them has never been our philosophy, so I don't see why we should add them at this point. Can we just get minimal functionality and see what people ask for --- they might ask for something completely different from what we have spec'ed out here, and if they do, we will have to remove existing options to meet their needs, or maintain a bloat of options. You know I have no problems adding options to make common tasks easier for our users, but we have no usage cases yet to know what they want. Our GUI tool uses only -G and -M (we may need to resort to -m soon, so we would like that one to be preserved as well). The remaining ones are related to its use as a command line utility and meant to produce readable output. I guess some options were indeed requested to limit the amount of info printed. BTW, it was a separate utility at that time: pg_guc. Aizaz was asked to transform it into a postgres --help-config option. I think --help-config needs to be a postgres flag, but the output format flags should be in a separate utility, perhaps not one we ship with PostgreSQL. I would not have a problem with a separate tool, perhaps in the src/tools directory, that would parse the output into all sorts of formats. I am just learning Perl, but I bet I could do it. The advantage of a src/tools script is that it is isolated, doesn't have to be documented as thoroughly, and can even be adjusted
Re: [HACKERS] postgres --help-config
On Tue, 14 Oct 2003, Bruce Momjian wrote: I knew you were adding --help-config, but I didn't realize the extent of the features. The commit message is: revision 1.1 date: 2003/07/04 16:41:21; author: tgl; state: Exp; Add --help-config facility to dump information about GUC parameters without needing a running backend. Reorder postgresql.conf.sample to match new layout of runtime.sgml. This commit re-adds work lost in Wednesday's crash. which I thought was a single option, which we all knew was needed, not six additional options for output format. Also, with no documention, or a posted list of the flags you wanted to add (at least I never saw it), it was easy to miss. Is there a mailing list somewhere that all the CVS commits get sent to? Other projects I've worked on have such a list, and each commit message is followed by a complete diff (usually with -u for readability) so even non-committers can do a code read right then and there while the changes are still fresh in the author's mind and can be discussed in detail. If such a list already exists, where do I subscribe? If not, don't you think it would be helpful in spreading around fuller knowledge of changes to the codebase? Jon ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] postgres --help-config
On Tue, Oct 14, 2003 at 07:52:55PM +, Jon Jensen wrote: Is there a mailing list somewhere that all the CVS commits get sent to? Yes, pgsql-committers. Other projects I've worked on have such a list, and each commit message is followed by a complete diff (usually with -u for readability) so even non-committers can do a code read right then and there while the changes are still fresh in the author's mind and can be discussed in detail. I wouldn't want the whole diff on the mail, but a link to the relevant diffs in cvsweb would be most useful (one for each changed file -- not ideal, but much better than nothing). You're not the first one to suggest it ... -- Alvaro Herrera ([EMAIL PROTECTED]) El destino baraja y nosotros jugamos (A. Schopenhauer) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgres --help-config
-Original Message- From: Jon Jensen [mailto:[EMAIL PROTECTED] Sent: 14 October 2003 20:53 To: [EMAIL PROTECTED] Subject: Re: [HACKERS] postgres --help-config Is there a mailing list somewhere that all the CVS commits get sent to? Other projects I've worked on have such a list, and each commit message is followed by a complete diff (usually with -u for readability) so even non-committers can do a code read right then and there while the changes are still fresh in the author's mind and can be discussed in detail. If such a list already exists, where do I subscribe? If not, don't you think it would be helpful in spreading around fuller knowledge of changes to the codebase? Please see: http://archives.postgresql.org/pgsql-committers/ Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] postgres --help-config
On Tue, 2003-10-14 at 15:57, Alvaro Herrera Munoz wrote: On Tue, Oct 14, 2003 at 07:52:55PM +, Jon Jensen wrote: Other projects I've worked on have such a list, and each commit message is followed by a complete diff (usually with -u for readability) so even non-committers can do a code read right then and there while the changes are still fresh in the author's mind and can be discussed in detail. I wouldn't want the whole diff on the mail, but a link to the relevant diffs in cvsweb would be most useful (one for each changed file -- not ideal, but much better than nothing). You're not the first one to suggest it ... I agree, it would be very useful. Marc, would it be possible to set this up? -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
I wouldn't want the whole diff on the mail, but a link to the relevant diffs in cvsweb would be most useful (one for each changed file -- not ideal, but much better than nothing). You're not the first one to suggest it ... I agree, it would be very useful. Marc, would it be possible to set this up? I volunteer to provide a patch (after 7.4 release) to CVSMODULES to do this for emails and the $PostgreSQL$ bit. It will be based upon the freely available FreeBSD code line. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] postgres --help-config
On Tue, 14 Oct 2003, Rod Taylor wrote: I wouldn't want the whole diff on the mail, but a link to the relevant diffs in cvsweb would be most useful (one for each changed file -- not ideal, but much better than nothing). You're not the first one to suggest it ... I agree, it would be very useful. Marc, would it be possible to set this up? I volunteer to provide a patch (after 7.4 release) to CVSMODULES to do this for emails and the $PostgreSQL$ bit. It will be based upon the freely available FreeBSD code line. FreeBSD's CVS scripts are the ones I've used too, and they work well. Perhaps it would make sense to have a separate mailing list so people who only want to see commit notices and not full diffs will be happy? Personally I don't find commit notices without diffs very useful -- if forced to choose, I'd rather have diffs without notices. :) But I can understand people not wanting to deal with the huge increase in message sizes if they're on a slow dial-up link or whatever. Jon ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Bruce Momjian writes: Let me be clear on this --- your tools is not part of the PostgreSQL community. We are not required to allow any of this functionality unless the community decides they want it. The major argument for keeping it, in my mind, is to be helpful to Red Hat. My current idea is to keep --help-config as readable output, add --help-config-raw as machine-readable output, document those, and remove all the additional flags. I'm beginning to think that we should scrap it and start with a real design for 7.5. I know that's radical, but I don't think we're going to arrive at anything that anyone's going to like by the time we want to release. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Peter Eisentraut wrote: Bruce Momjian writes: Let me be clear on this --- your tools is not part of the PostgreSQL community. We are not required to allow any of this functionality unless the community decides they want it. The major argument for keeping it, in my mind, is to be helpful to Red Hat. My current idea is to keep --help-config as readable output, add --help-config-raw as machine-readable output, document those, and remove all the additional flags. I'm beginning to think that we should scrap it and start with a real design for 7.5. I know that's radical, but I don't think we're going to arrive at anything that anyone's going to like by the time we want to release. The problem is how that affects Red Hat. What do they do with their tool? I was hoping we could get a minimal setup for them to access those variables so they could move forward. Let me add I know these admin tools are very popular with support companies. I know SRA has an admin tool that can control postgresql.conf variables. My guess is that they did it by hacking their version of PostgreSQL. Looks like they have new URL showing their Win32 and enhanced PostgreSQL products (English auto-translation): http://www.excite.co.jp/world/url/body?wb_url=http%3A%2F%2Fpowergres.sra.co.jp%2Fwb_lp=JAENwb_dis=2 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I'm beginning to think that we should scrap it and start with a real design for 7.5. I know that's radical, but I don't think we're going to arrive at anything that anyone's going to like by the time we want to release. The problem is how that affects Red Hat. What do they do with their tool? I believe said tool is within a couple days of code freeze for initial release, in fact. We could probably still cope with a change in the spelling of the switches, but redesigning the output format or removing the functionality altogether would be a very nasty surprise. Let me be clear on this --- your tools is not part of the PostgreSQL community. We are not required to allow any of this functionality unless the community decides they want it. I'm really having a hard time responding to this line of argument politely. Where were all these complaints when the patch was proposed and accepted? If there's not time now to redesign the feature to your liking, it is *NOT* Red Hat's fault, it is *YOURS*. Yanking the rug out from under someone else's project just because you didn't review the patch adequately at the time is not my idea of how a community should act. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: I'm beginning to think that we should scrap it and start with a real design for 7.5. I know that's radical, but I don't think we're going to arrive at anything that anyone's going to like by the time we want to release. The problem is how that affects Red Hat. What do they do with their tool? I believe said tool is within a couple days of code freeze for initial release, in fact. We could probably still cope with a change in the spelling of the switches, but redesigning the output format or removing the functionality altogether would be a very nasty surprise. Let me be clear on this --- your tools is not part of the PostgreSQL community. We are not required to allow any of this functionality unless the community decides they want it. I'm really having a hard time responding to this line of argument politely. Where were all these complaints when the patch was proposed and accepted? If there's not time now to redesign the feature to your liking, it is *NOT* Red Hat's fault, it is *YOURS*. Yanking the rug out from under someone else's project just because you didn't review the patch adequately at the time is not my idea of how a community should act. I thought you might have an emotional reaction to this issue. I did not review these changes thoroughly because: o There was no proposal on the switches and their usage. o The commit message didn't mention any switches other than --help-config. o There are no docs to show the new flags. o You were handling it, and I trusted your style, so I didn't see a reason to study it more thoroughly. Let's imagine how this would have worked for an outside project/company: o Project leader comes to us and says they want to make a PostgreSQL admin tool. o They explain their needs and we agree on how to implement it. o We implement the feature as discussed. Would we have agreed to adding all those flags? I don't think so. We would have given them a clean output, and asked them to handle the functionality in their code, which is probably the correct approach. This procedure is in our developer's FAQ: The usual process for source additions is: o Review the TODO list. o Discuss hackers the desirability of the fix/feature. o How should it behave in complex circumstances? o How should it be implemented? o Submit the patch to the patches list. o Answer email questions. o Wait for the patch to be applied. Now, we have Red Hat having you add a patch on July 4 (posted for review June 30), very near feature freeze, but it meets a discussed need (--help-config), so it goes in. I only learned about it when Peter saw the C code handling the new flags and asked questions about it. I do see the patch submitted, with clear illustration of the flags: http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php I guess I thought those flags were for Red Hat's tool or a separate utility, but it clearly states it is part of the postgres binary, so that was my fault. It looks like this all became visible on September 29: http://groups.google.com/groups?hl=enlr=ie=UTF-8threadm=29402.1065021420%40sss.pgh.pa.usrnum=2prev=/groups%3Fq%3Dhelp-config%2Bgroup:comp.databases.postgresql.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.databases.postgresql.*%26selm%3D29402.1065021420%2540sss.pgh.pa.us%26rnum%3D2 I think I am agreeing with Peter's comment in that email thread: I'm quite unhappy about the --help-config option. It was developed without discussion, it was installed hastily, we don't have any information about that interactive configuration application it's supposed to target, it's not documented, it's full of unfinished business, it certainly doesn't make the code easier to maintain because all the documenation is duplicated, but not one-to-one. At this point, I wouldn't spend a lot of time trying to make sense of it. We can revisit it again in the next release and investigate how we can eliminate the duplication of effort between the documentation and the code. We certainly want to keep Red Hat happy. Will Red Hat be upset if we leave it unchanged for 7.4.X and rip this out and redo it in 7.5? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: ... Will Red Hat be upset if we leave it unchanged for 7.4.X and rip this out and redo it in 7.5? It'd be better if we could get it right the first time, with the understanding that the output format is not very negotiable at this late hour. But as best I can tell, most of the unhappiness is with the design of the switch set, which is not something I want to defend in detail. There's a lot there that isn't needed for the RHDB tool as I understand it, and I think that altering the switches used to get the output that the tool does need would still be a feasible change from the tool's point of view. I would be in favor of simplifying the supported switch set to the minimum needed by Red Hat's tool (the equivalent of -G -M if I understood Fernando correctly), and re-adding complexity in future when and if it's shown to be needed. But we need to make a decision about this now. Preferably yesterday. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] postgres --help-config
Where should I start on this? :-) The implementation of postgres --help-config has several issues: o it has options added just in case someone ever need them o it has capital letters to negate, which we have never used before o uses GNU message reporting style o there was little discussion about how this should work Its biggest plus is that it isn't documented :-) --- because the API might change in the next release, and no one wants to stand up for this. If Red Hat didn't do so much for PostgreSQL by hiring Tom and others, I would be more upset, but putting something in for the convenience of some Red Hat tool isn't something I would like to see happen regularly, and I think we can all agree on that. I can't even put a mention on the TODO that this has to be cleaned up because I would then advertise it. I will put it on my personal list and we can discuss how this is supposed to for for 7.5. --- Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: [ some questions about --help-config ] I got this reply from Fernando Nasser of Red Hat. I suggested he should post it for himself, but since he hasn't yet... regards, tom lane --- Forwarded Message Date:Tue, 30 Sep 2003 11:24:50 +0200 (CEST) From:Peter Eisentraut [EMAIL PROTECTED] (...) OK, but does this tool actually need all of the following features: -G -- do not group by category both -m and -M -- machine-readable output with and without header human-readable output Were some of these just added for completeness? With what rationale? -m and -M The utility we designed and possibly any other that wants to process the output will find it easier to process a more regularly formed output instead of one that was embellished for human viewing. The reason for having one with and one without headings is that in some circumstances the utility designer may want to use the headers to make her/his table headers and others may prefer to have pre-defined table headers. The guy who wrote our window used -M while I would have liked him to use -m (but -M was faster to do and he was on a hurry). -G The -G (using the Unix convention of negating things with capital letters) is what we use. This option is probably what will be used for generating the postgresql.conf default file automatically. As we were not adding a facility for our use but for other tool developers as well and we thought that some may want to process it in different ways we made it an option. We don't object making it a side effect of using -m or -M. Also, --help-config 'foo' outputs all parameters matching 'foo' somewhere in the string, not only 'foo'. I think that is a misdesign. It works like locate (or slocate). I believe some other Unix utilities do the same. Unix commands are mostly 'misdesigned' I admit. I had a '-re' which accepted a regular expression. With that re-added one could make the --help-config 'foo' works like Peter wants. But I would put that for a vote: I wouldn't be surprised if Peter were in a minority on this issue. postgresql.conf. The long descriptions were what the GUI tool wants. Tom, actually the tool (as I believe from previous experience with command line help facilities) needs both. The short description shows up in summaries where you have a list of options and not much space. The long description shows up in specific help commands, as tooltips etc., whenever the user wants and you can provide more information. Most parameters don't have long descriptions, so that doesn't seem right. When the meaning is obvious there is no need to re-state it. There may be cases where a better description should be written and it is only empty because nobody yet knows exactly what it does, or could not come up with a proper description (whenever a description was available in the documentation the field was filled). Also, in many cases where there is a long description, it was copied out of the documentation, with the short description being the first sentence and the long description being the rest. The result is that in some cases the long description doesn't make sense in isolation. I would like that to be clarified. This is a GNU trick to avoid repeating the same text (from the short description) in the long description. I believe it is from Richard Stallman's time. It is used in several GNU tools, for instance the GNU GDB debugger (which uses just one field and makes the first sentence or line the short description). The idea is that the long description is formed by the concatenation of the two. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto,
Re: [HACKERS] postgres --help-config
Bruce Momjian [EMAIL PROTECTED] writes: Where should I start on this? :-) Where should I start on all the people who are complaining now, but said not a word when the patch was put up for review? I'm quite annoyed at these claims that procedure wasn't followed. It's either selective memory or historical revisionism, and either way I feel it's unfair to me and to Red Hat. Let's see some specific suggestions for improvement, rather than bootless complaining. I'm quite prepared to agree that the patch could use improvement. If we can fix it before 7.4 release, let's do so. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Where should I start on this? :-) Where should I start on all the people who are complaining now, but said not a word when the patch was put up for review? I'm quite annoyed at these claims that procedure wasn't followed. It's either selective memory or historical revisionism, and either way I feel it's unfair to me and to Red Hat. Let's see some specific suggestions for improvement, rather than bootless complaining. I'm quite prepared to agree that the patch could use improvement. If we can fix it before 7.4 release, let's do so. Oh, OK. I thought you wanted it unchanged in the code, and we were going to deail with it later. It just doesn't _seem_ to match our style. Let me look at it and I will repost. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres --help-config
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Where should I start on this? :-) Where should I start on all the people who are complaining now, but said not a word when the patch was put up for review? I'm quite annoyed at these claims that procedure wasn't followed. It's either selective memory or historical revisionism, and either way I feel it's unfair to me and to Red Hat. Let's see some specific suggestions for improvement, rather than bootless complaining. I'm quite prepared to agree that the patch could use improvement. If we can fix it before 7.4 release, let's do so. OK, I have some ideas. Because you didn't document it, and couldn't get Fernando to post a reply to Peter's questions, I assumed you didn't want to work on it right now, and that it was in there just for Red Hat. First, the default output should have the sorted field first. It appears the default is to sort by context: postgres --help-config That should be the first printed field. However, I see you can sort by Group, so maybe group should always be first --- that seems most logical. The documentation I see is the command-line help in the C file: printf(gettext(Usage:\n %s --help-config [OPTION]... [NAME]\n\n), progname); printf(gettext(General Options:\n)); printf(gettext( NAME output information about parameters matching this name\n)); printf(gettext( -g GROUP output information about parameters matching this group\n)); printf(gettext( -llist available parameter groups\n)); printf(gettext( -hshow this help, then exit\n)); printf(gettext(\nOutput Options:\n)); printf(gettext( -G do not group by category\n)); printf(gettext( -m machine-friendly format: tab separated fields\n)); printf(gettext( -M same as -m, but header with column names is suppressed\n)); I don't see any value to most of these parameters, and the add them in case they might need them has never been our philosophy, so I don't see why we should add them at this point. Can we just get minimal functionality and see what people ask for --- they might ask for something completely different from what we have spec'ed out here, and if they do, we will have to remove existing options to meet their needs, or maintain a bloat of options. You know I have no problems adding options to make common tasks easier for our users, but we have no usage cases yet to know what they want. What would make sense is to always output sorted by Group/Name, and see how that works for folks. I also didn't think the dashed lines were needed --- they seemed to clutter the output: Name: preload_libraries Context: postmaster Group: Resource Usage / Kernel Resources Type: string Default value: Description: shared libraries to preload into server Name: fsync Context: sighup Group: Write-Ahead Log / Settings Type: Boolean Default value: true Description: force synchronization of updates to disk The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This insures that a database cluster will recover to a consistent state after an operating system or hardware crash. vs. Name: preload_libraries Context: postmaster Group: Resource Usage / Kernel Resources Type: string Default value: Description: shared libraries to preload into server Name: fsync Context: sighup Group: Write-Ahead Log / Settings Type: Boolean Default value: true Description: force synchronization of updates to disk The server will use the fsync() system call in several places to make sure that updates are physically written to disk. This insures that a database cluster will recover to a consistent state after an operating system or hardware crash. An output that uses --help-config, and takes no flags seems like the way to go at this point. If people want specific entries, they can page through them with less, or use a tool to extract them from the text file --- the output is in a very clear format. I would also indent the text description (last line) to line up with the other data fields. Is that enough feedback? :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania
