On Thu, 6 Jul 2000, Peter Eisentraut wrote:
>
> > Even if we agree that various *output* date styles are not useful, the
> > DateStyle setting also affects the interpretation of input date/time
> > (e.g. month/day or day/month conventions). istm that a lot of apps do
> > need some flexibility in date/time inputs.
>
> I've been meaning to ask about that, might as well do it now. As you say,
> the DateStyle setting is overloaded for two separate things: default
> output style (ISO, "SQL", Postgres, German), and month/day vs day/month
> setting. This has always confused me (and presumably not only me) and it
> is quite tricky to integrate this into my options work -- there is no
> family of settings for "takes a string input and sets two integer
> variables".
>
> Maybe we could split this up:
>
> * datetime_output_style: one of ISO, SQL, Postgres, German
>
> (In fact, if we wanted, we could also make this an arbitrary to_char()
> format string. If it's empty we default to ISO, if it's set then we pass
> it right on to to_char. I guess then we'd need separate parameters for
> date and time though.)
I not sure, but if I good remember for example Oracle has something like
SET DATESTYLE TO 'arbitrary style', where style is defined via to_char
templates. For example:
SET DATESTYLE TO 'YYYY Month-DD HH:MI:SS'
and all date/time (like now()) outputs will formatted via this setting in
to_char "engine". IMHO create support for this is possible. I will think
about it for 7.2
This solution can forever stop all discussion about styles that PG
must/can support.
Karel
