Re: [HACKERS] postgres and year 2000

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Stupor Genius <stuporg(at)erols(dot)com>
Cc: Pgsql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] postgres and year 2000
Date: 1999-01-14 06:59:08
Message-ID: 369D95BC.631ABDD9@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-01-14 10:38:15 Re: [HACKERS] CONSTRAINTS...
Previous Message Thomas G. Lockhart 1999-01-14 06:11:02 Re: [HACKERS] SUM() and GROUP BY