Re: GUC names in messages

Laurenz Albe <laurenz.albe@cybertec.at>

From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Smith <smithpb2250@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Nathan Bossart <nathandbossart@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-28T07:05:02Z
Lists: pgsql-hackers
On Tue, 2023-11-28 at 07:53 +0900, Michael Paquier wrote:
> On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> > Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
> > > > In the documentation and in the guc_tables.c they are all described in
> > > > MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
> > > > messages should use the same case the documentation, which is why I
> > > > changed all the ones you are referring to.
> > 
> > > I agree with that decision; we should use mixed case for these parameters.
> > > Otherwise we might get complaints that the following query does not return
> > > any results:
> > >   SELECT * FROM pg_settings WHERE name = 'timezone';
> 
> (I'm sure that you mean the opposite.  This query does not return any
> results on HEAD, but it would with "TimeZone".)

No, I meant it just like I said.  If all messages suggest that the parameter
is called "timezone", and not "TimeZone" (because we convert the name to lower
case), then it is surprising that the above query does not return results.

It would be better to call the parameter "TimeZone" everywhere.

(It would be best to convert the parameter to lower case, but I am worried
about the compatibility-pain-to-benefit ratio.)

Yours,
Laurenz Albe



Commits

  1. Apply GUC name from central table in more places of guc.c

  2. Use camel case for "DateStyle" in some error messages

  3. Unify some error messages to ease work of translators

  4. Apply more quoting to GUC names in messages

  5. Revise GUC names quoting in messages again

  6. doc: Mention how to use quotes with GUC names in error messages

  7. Apply quotes more consistently to GUC names in logs