On Fri, 7 Jul 2000, Thomas Lockhart wrote:
> > This solution can forever stop all discussion about styles that PG
> > must/can support.
>
> This is one thing I'm *not* certain about. The problems with a fully
> general, templated formatting function for the backend include
>
> 1) It is easy to make a date/time template which *cannot* be used to
> read data back in. So, for example, pg_dump could be fundamentally
> broken just be this setting. Currently, input and output are always
> compatible (more or less ;)
full support for in/out is expect in this idea, and we can add check
that conterol if defined template is right for timestamp interpretation.
> 2) There may be a performance hit to *always* use a fully general
> template for formatting.
Not sure. The to_char/timestamp is fast and parsed template is cached,
IMHO is not big (speed) differention between to_char/timestamp and standard
date/time formatting.
> 3) If the template is used for output, it should probably be used for
> input (to minimize the possibility of (1)). But then we would be able to
> accept fewer date/time variations than we do now.
With this setting is all in user's hands...
I don't know how much problematic it is, but the oracle has this feature
(NSL_DATE_FORMAT in ALTER SESSION, etc)
But I not say that we must implement this, it is still open thema :-)
Karel
