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    WRONGto_char(integer,text)                     | i |
int4_to_char       WRONGto_char(bigint,text)                      | i | int8_to_char        WRONGto_char(real,text)
                  | i | float4_to_char        WRONGto_char(double precision,text)            | i | float8_to_char
WRONGto_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    OKto_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_dateto_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