Re: Day and month name localization uses wrong

I wrote:
> I think the only interesting question is whether we should force initdb
> in HEAD.

I take that back; there's something possibly worth discussing in the
markings themselves. What I find after experimentation is:

* These functions pay attention to LC_NUMERIC, and have since at least
7.3, and therefore should be marked STABLE in all branches:

to_char(numeric,text) | i | numeric_to_char WRONG
to_char(integer,text) | i | int4_to_char WRONG
to_char(bigint,text) | i | int8_to_char WRONG
to_char(real,text) | i | float4_to_char WRONG
to_char(double precision,text) | i | float8_to_char WRONG
to_number(text,text) | i | numeric_to_number WRONG

* These functions are already correctly marked STABLE, because they have
depended on TimeZone all along:

to_char(timestamp with time zone,text) | s | timestamptz_to_char OK
to_timestamp(text,text) | s | to_timestamp OK

* This function is clearly mis-marked as of HEAD, because of its new
dependence on LC_MESSAGES (but shouldn't be changed in back branches):

to_char(timestamp without time zone,text) | i | timestamp_to_char

* These functions appear to still not depend on any GUC variable:

to_date(text,text) | i | to_date
to_char(interval,text) | i | interval_to_char

It's the last two that are bothering me. It seems likely that somebody
will soon fix to_date() to support input as well as output using the
localizable format items. Should we mark it stable now, rather than
risk missing this again? How about to_char for intervals --- it seems
we currently have INVALID_FOR_INTERVAL on all localizable format items,
but is that going to be true forevermore?

I'm much tempted to mark the last two STABLE as well, and just have a
consistent rule that all the formatting functions are stable. Thoughts?

regards, tom lane