Thread: Why some GUC parameter names are not lowercased

Gurjeet Singh <singh.gurjeet@gmail.com> writes:
> Is there a reason why Postgres chose to not use all lowercase characters
> for these parameters' names.
>  DateStyle
>  IntervalStyle
>  TimeZone

It's historical, for sure.  I think we've discussed changing them and
decided it would be more likely to break things than improve matters.

In particular, modern style would probably be more like "date_style"
etc, but we definitely could not insert underscores without breaking
applications all over the place.  So the best we could do is just
smash to lowercase, eg "datestyle", which isn't really a readability
improvement.  And there would still be some risk of breaking
applications that are expecting these names to print a particular way.

            regards, tom lane

Gurjeet Singh <singh.gurjeet@gmail.com> writes:
> On Tue, Oct 30, 2012 at 12:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Gurjeet Singh <singh.gurjeet@gmail.com> writes:
>>> Is there a reason why Postgres chose to not use all lowercase characters
>>> for these parameters' names.

>> It's historical, for sure.  I think we've discussed changing them and
>> decided it would be more likely to break things than improve matters.

> Can we develop aliases to these parameters, that adhere to the standard.
> Next release we can mark the old ones as deprecated and a few releases down
> the line  completely remove the non-stsandard names and rest easy.
> Would be happy to contribute such a patch. I think it'd be trivial.

Sure, breaking things is trivial.  *Not* breaking things requires hard
decisions.  In this case, I don't see that a small improvement in
consistency is worth the side-effects it's likely to have on
applications.  In particular, I don't believe we could ever remove the
aliases, and even if we did have aliases that doesn't fix the problem of
applications expecting the names to display in a particular way.  That's
not a hypothetical problem either.  The names of these three settings
are effectively part of the wire protocol, since the backend
automatically generates ParameterStatus messages for them.  At the very
least we'd have to generate duplicate ParameterStatus messages for them
for the foreseeable future, which imposes a real communication cost (to
say nothing of whatever violence you'd have to do to the guc.c code to
make it happen).

We have made this sort of change before (eg, sort_mem => work_mem),
but only with substantially more reason to do it than this, and for
settings that applications are substantially less likely to request the
values of.

            regards, tom lane