Re: BUG #3563: DATESTYLE feature suggestion - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #3563: DATESTYLE feature suggestion
Date
Msg-id 9076.1187801345@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #3563: DATESTYLE feature suggestion  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> Yea, it isn't too hard to do, especially for output;  input might be
> harder.  This is the first request we have ever gotten for this so it is
> doubtful we would add this feature unless there is more demand.

I don't think any input-side changes are being requested here; the input
reader is already flexible enough to cope with nearly any sane format.
The complaint is evidently that he shouldn't have to use to_char() to
produce an *output* format of his liking.

I'm far from convinced that we should allow any arbitrary output format,
since it's easy to imagine shooting yourself in the foot that way by
making something the input reader wouldn't recognize reliably.  But
I think we could consider redesigning the datestyle feature to offer a
wider set of known-safe formats.  We already did this on the input side
--- remember the old "euro" kluge?  We now have MDY/DMY/YMD, which is to
my mind a lot better design.  On the output side we still have
ISO/SQL/POSTGRES/GERMAN, which just reeks of non orthogonality.

ISTM the base features you'd want to control are date field order, the
date field separator character (slash dash or dot are probably
sufficient), and whether month is numeric or not.  Perhaps a design
oriented around that type of breakdown might fly.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: BUG #3563: DATESTYLE feature suggestion
Next
From: "Ken Colson"
Date:
Subject: BUG #3571: call to decrypt causes segfault