> > Not compile-time, no. But I think it would be a good thing to have
> > several run-time options (of which PostgreSQL already has a few), to
> > specify exactly which behavior is wanted. For two digit years, it
> > might be useful to be able to specify to the backend that they should
> > be handled as, say, 1920-2019, or as the chronologically nearest year
> > that ends in the two given digits, or maybe even as being in the
> > current century. When using a four digit year mode, though, I think
> > it's a good idea to handle '99' as the year 99, and not e.g. 1999.
>
> IIRC, we already have both behaviors (99->1999AD and 99->99AD)
> available, but it's controlled by a combination of the DATESTYLE setting
> and the actual formatting of the particular input string.
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?
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.
The latter would seem to be the easiest solution and allow the
user to enter many different date styles per connection simply
by issing a "SET DATESTYLE = 'abc-xyz'".
Thomas, how hard would it be to parse an arg to "SET DATESTYLE"
and use it to parse dates?
Just my thoughts...
darrenk