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
