Re: BUG #3563: DATESTYLE feature suggestion
От | Russell Smith |
---|---|
Тема | Re: BUG #3563: DATESTYLE feature suggestion |
Дата | |
Msg-id | 46CC1842.702@pws.com.au обсуждение исходный текст |
Ответ на | Re: BUG #3563: DATESTYLE feature suggestion (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: BUG #3563: DATESTYLE feature suggestion
|
Список | pgsql-bugs |
Heikki Linnakangas wrote: > 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. > > I'm curious, what datestyle do you need? The current datestyle GUC > variable provides the most common ones already. > The issue is output, not input. SET datestyle='dmy'; SELECT '03-03-2004'::date Will return '2007-03-03', not 03-03-2004 as is the set datestyle. Regards Russell
В списке pgsql-bugs по дате отправления: