Re: GUC context information in the document.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: GUC context information in the document.
Date: 2015-03-31 19:07:08
Message-ID: 24663.1427828828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> If I'm not missing anyting, putting stereotyped information about
> GUC contexts like following would be usable.

>> share_buffers (integer), (effective after server restart)

>> log_destination (string), (effetive after config reload)

>> log_min_duration_statement (integer), (effective in-session, superuser only)

>> DateStyle (string), (effective in-session)

> What do you think about this?

TBH, those don't seem like improvements over the existing boilerplate
texts, particularly not the last two.

I follow the general idea of getting rid of the boilerplate sentences
in favor of an annotation similar to the variable datatype notations;
but such annotations would have to be *very* carefully wordsmithed
to be both precise and understandable yet brief enough to fit ... and
these are not. I'm not sure such a goal is possible at all.

If we were to go in this direction, I'd favor just annotating with
the same context keywords that we already expose to users in the
pg_settings view, ie more like

shared_buffers (integer, postmaster context)

and then we'd need some introductory text in section 18.1 that defines
these keywords. Maybe we could move the text about them that's currently
associated with the pg_settings view (section 48.69 ATM).

But TBH, I'm not sure that anything like this would reduce the number
of questions. It's basically relying on the assumption that people would
read section 18.1 before asking, and that's a shaky assumption.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-03-31 19:09:26 clang -fsanitize=undefined error in ecpg
Previous Message Tomas Vondra 2015-03-31 19:02:29 Re: PATCH: adaptive ndistinct estimator v4