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
Yeah, I haven't thought of a real satisfactory name either. Do you
> If, on the other hand, we like the code to know about categories,
> should this code be capable of generating the sample file
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
> 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
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
> 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
pgsql-patches by date
|Next:||From: Joe Conway||Date: 2003-07-01 00:37:02|
|Subject: Re: [HACKERS] Missing array support|
|Previous:||From: Tom Lane||Date: 2003-07-01 00:15:12|
|Subject: Re: [HACKERS] Missing array support |