"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 4/7/22 8:36 AM, Joe Conway wrote:
>> I will say that I care about context far more often than unit or type
>> though, so from my point of view I would switch them around with respect
>> to which is only shown with verbose.
> I disagree somewhat -- I agree the context should be in the regular
> view, but unit and type are also important. If I had to choose to drop
> one, I'd choose type as it could be inferred, but I would say better to
> keep them all.
Given the new ability to grant privileges on GUCs, context alone is not
sufficient to know when something can be set. So the context and the
privileges seem like they should go together, and that's why I have them
both under "+".
I can see the argument for relegating type to the "+" format, in hopes of
keeping the default display narrow enough for ordinary terminal windows.
> A couple of minor things:
> + appendPQExpBufferStr(&buf, "ORDER BY 1;");
> I don't know how much we do positional ordering in our queries, but it
> may be better to explicitly order by "s.name".
"ORDER BY n" seems to be the de facto standard in describe.c. Perhaps
there's an argument for changing it throughout that file, but I don't
think this one function should be out of step with the rest.
> I don't know if we want to throw a "LOWER(s.name)" on at least the
> ordering, given we allow for "SHOW" itself to load these case-insensitively.
Yeah, I went back and forth on that myself --- I was looking at the
example of DateStyle, and noticing that although you see it in mixed
case in the command's output, tab completion isn't happy unless you
enter it in lower case (ie, date<TAB> works, Date<TAB> not so much).
Forcibly lowercasing the command output would fix that inconsistency,
but on the other hand it introduces an inconsistency with what the
pg_settings view shows. Not sure what's the least bad. We might be
able to fix the tab completion behavior, if we don't mind complicating
tab-complete.c even more; so probably that's the thing to look at
before changing the output.
> Maybe to appeal to all crowds, we say "list configuration parameters
> (GUCs)"?
I'm in the camp that says that GUC is not an acronym we wish to expose
to end users.
regards, tom lane
