> 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
