Skip site navigation (1) Skip section navigation (2)

Re: Patch for listing runtime option details through server executable (pg_guc)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Aizaz Ahmed <aahmed(at)redhat(dot)com>, pgsql-patches(at)postgresql(dot)org,Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: Patch for listing runtime option details through server executable (pg_guc)
Date: 2003-07-01 00:30:34
Message-ID: 20906.1057019434@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> If the option is named --long-help, I'd expect a longer version of
> --help, which this is not.  The name should probably involve "help"
> and "config" to make it clearer what you get.  (Personally, I think
> "help" should go before the qualifying word, but there may be other
> opinions.)

Yeah, I haven't thought of a real satisfactory name either.  Do you
like "--help-config"?

> If, on the other hand, we like the code to know about categories,
> should this code be capable of generating the sample file
> automatically?

There was something about that in the back of the mind, but I'd prefer
to take that as a long-term goal rather than try to make it happen
right now.

> To mark up string literals, where you use translatable(), there is
> already a standard function gettext_noop() available.

Ah.  The translatable() was my suggestion --- I'd forgotten we had
another macro already defined.  (But why doesn't nls.mk mention it?
Or is that name built into the gettext tools?)

> There is already a file guc.c, why should there be a file pg_guc.c
> now?  That doesn't make sense; the names should be differentiated
> better.

The name pg_guc.c is left over from the original intent of having
a standalone tool named pg_guc.  We could fold it together with
guc.c, but I think it is cleaner to keep it as a separate file.
If you have a better name for it, that's fine with me...

> Why have various things been moved from guc.h to guc_vars.h, which
> seems to just split things up uselessly?

So that pg_guc.c can get at the constant tables in guc.c.  Admittedly,
this would go away if we fold the two together, but I think that's
the wrong thing.  pg_guc is still a small standalone program in concept
;-) ... it is just sharing an executable with the backend.

> Why are there long explanations in some cases only?  Do you plan to
> add others later?  I also think the messages should be made more
> consistent in various ways, but that can be done later.

Yeah, I had some editorializing to do too.  This is not on the critical
path though.

> Should options not for general use (e.g., session_auth_is_superuser)
> be hidden from this tool?  Are they?  What other provisions of this
> kind does this tool make?

The original intent of the standalone tool was to display stuff that
could usefully be set in postgresql.conf, and I think it's important
to maintain that as an available behavior (though I wouldn't object
to making other subsets available as well).  The patch includes a
couple more flag bits to try to identify the behaviors of various
variables.  (I've not checked Aizaz' settings for the flags though,
there might be some mistakes.)

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Joe ConwayDate: 2003-07-01 00:37:02
Subject: Re: [HACKERS] Missing array support
Previous:From: Tom LaneDate: 2003-07-01 00:15:12
Subject: Re: [HACKERS] Missing array support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group