| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: consider including server_version in explain(settings) |
| Date: | 2019-10-03 19:46:48 |
| Message-ID: | 28117.1570132008@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> This is a "concept" patch to show the version, which is frequently requested on
> -performance list and other support requests. If someone sends
> explain(settings), they don't need to also (remember to) send the version..
I'm not really on board with the proposal at all here; I think it'll
be useless clutter most of the time. I do not agree with the position
that the only use-case for explain(settings) is performance trouble
reports. Moreover, if we start including fixed settings then where
do we stop? People might also want "pg_config" output for example,
and that's surely not reasonable to include in EXPLAIN.
Independently of that, however:
> /* skip GUC variables that match the built-in default */
> - if (!modified)
> + if (!modified && strcmp(conf->name, "server_version_num"))
> continue;
This is both horribly contorted logic (it could at least do with a
comment) and against project coding conventions (do not use the result
of strcmp() as if it were a boolean).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-10-03 20:13:05 | Re: fairywren failures |
| Previous Message | Justin Pryzby | 2019-10-03 18:44:09 | consider including server_version in explain(settings) |