Re: [HACKERS] postgres and year 2000
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] postgres and year 2000 |
Дата | |
Msg-id | 369D95BC.631ABDD9@alumni.caltech.edu обсуждение исходный текст |
Ответ на | RE: [HACKERS] postgres and year 2000 ("Stupor Genius" <stuporg@erols.com>) |
Список | pgsql-hackers |
> Why not just try to parse the date according to the DATESTYLE setting > and cough up an error if the date-parsing code doesn't find what it > is looking for? Postgres does use the DateStyle setting to resolve input ambiguities. > I believe Oracle does this, but also has the to_date(string, format) > function to tell the backend just what format it is getting. The > function also exists without the format arg in which case it will > use the Oracle default. > It seems to me that either ... > Postgres needs a to_date function to be told what format to use > instead of being expected to blindly guess what the user is giving > it. Then overload the function s.t. calling it without the format > will use the current DATESTYLE. > or > Postgres needs a way to set the DATESTYLE to the actual format > string to be used to parse the input for a date field instead of > being used to indicate a "style". This then eliminates the need > for the to_date function. So what problem are we trying to solve again? Stripping out functionality should buy us something useful... > Thomas, how hard would it be to parse an arg to "SET DATESTYLE" > and use it to parse dates? Not sure. It would just be a different set of parsing code. - Tom
В списке pgsql-hackers по дате отправления: