> Randolf Richardson wrote:
>
> > After convincing clients and colleagues to switch from Oracle (and others)
> > to PostgreSQL, an issue that comes up is the need to customize DATESTYLE.
> > Because this isn't possible, the developers who were against the move to
> > PostgreSQL make it political and recommended work-around solutions such as
> > using to_char() or implementing a view for each table that contain
> > TIMESTAMP[TZ]s is very difficult to argue with management because a lot of
> > time is required to implement these items.
> >
> > In a future version, to solve this problem, an additional DATESTYLE option
> > that uses the same rules as the to_char() function for date formatting would
> > solve this problem. Here's an example:
> >
> > SET DATESTYLE = 'Custom YYYY-Mon-DD';
> >
> > This feature would not only resolve this particular political strife, but
> > would also solve many other problems, including simplifying coding for raw
> > SQL output serving as reports (e.g., users still get confused about dates
> > like "2007-06-03," wondering if they refer to June 3rd, or March 6th).
> >
> > I'm hoping that this suggestion will be an easy one to implement.
>
> Probably wouldn't be too hard.
That's great! I'm guessing that this is due to the work already
done with the to_char() function.
> I'm curious, what datestyle do you need? The current datestyle GUC
> variable provides the most common ones already.
The datestyle I need is "YYYY-Mon-DD" so that reports can easily be
generated that show dates like 2007-Aug-22. For people reading the
output, there will be absolutely no confusion about what the date is.
But that's the format that I'm interested in (and I deal with many
others who really like it as well); I think that using the same rules
as to_char() would potentially serve everyone better than supplying a
special datestyle just to match my preference.
Thanks.
Randolf Richardson - randolf@richardson.tw
Vancouver, British Columbia, Canada
http://www.randolf.richardson.tw/
"Radio-active cats have 18 half-lives."