| 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) |