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
