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 по дате отправления: