Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> One might also ask why its set of
>> allowed values is inconsistent with the SET command's (probably
>> postgres.c ought to just call a routine in variable.c, rather than
>> having its own parsing code)?
> I'm vaguely recalling that there was a "chicken and egg" problem with
> the backend firing up... Ah, in fact I think (still from my sometimes
> faulty memory) that it had to do with whether the Postgres memory
> management stuff (palloc et al) was available at the time postgres.c
> needed to make the call.
Yup, your memory is still working...
> Feel free to review it though and make sweeping or small changes.
OK, I tweaked the code in variable.c to not depend on palloc(), and
made the change. In the course of doing so, I noticed what I assume
is a bug: RESET DateStyle and SET DateStyle = 'DEFAULT' were still
setting to Postgres style. Presumably they should reset to ISO style
in the brave new world, no?
What I actually did was to make them reset to whatever the backend's
startup setting is. Thus, if a postmaster PGDATESTYLE environment
variable exists, it will determine the result of RESET DateStyle as
well as the state of a new backend. (A client-side PGDATESTYLE setting
cannot affect RESET, of course, since it just causes a SET command to
be issued.) I think this is appropriate behavior, but it might be open
to debate.
BTW, here is an interesting corner case for you: what happens when
the postmaster is started with PGDATESTYLE="DEFAULT"? You get ISO
now, but I almost committed code that would have gone into infinite
recursion...
regards, tom lane