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
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 |