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 op
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
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.
>
>
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
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 br
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 post
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
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 doe
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 trans
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
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 s
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 th
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
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 "lo
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-rea
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 an
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 ne
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, w
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 struct
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 thr
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
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 representi
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,
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.
Wh
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
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 a
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
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 a
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
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 th
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 be
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
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
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
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 curre
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,
> > 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 possib
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
> -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 p
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 readabili
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 informatio
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
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://so
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 ()
"I dream about dreams about dreams", sang
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
[ back from San Jose, catching up on email ]
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is that enough feedback? :-)
Yup, thanks for the comments. I am not sure how much of the existing
--help-config functionality is actually needed by Red Hat's tool, so
I've asked those guys to respond.
Pers
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.
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.
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 o
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
50 matches
Mail list logo
