Skip site navigation (1) Skip section navigation (2)

Re: Rectifying wrong Date outputs

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Piyush Newe <piyush(dot)newe(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rectifying wrong Date outputs
Date: 2011-03-17 14:29:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Excerpts from Robert Haas's message of jue mar 17 11:09:56 -0300 2011:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:

> > Keep in mind that the datetime stuff was abandoned by the maintainer
> > some years ago with quite some rough edges.  Some of it has been fixed,
> > but a lot of bugs remain.  Looks like this is one of those places and it
> > seems appropriate to spend some time fixing it.  Since it would involve
> > a behavior change, it should only go to 9.2, of course.
> I wouldn't object to fixing the problem with # of digits > # of Ys in
> 9.1, if the fix is simple and clear-cut.  I think we are still
> accepting patches to make minor tweaks, like the tab-completion patch
> I committed yesterday.  It also doesn't bother me tremendously if we
> push it off, but I don't think that anyone's going to be too sad if
> TO_DATE('01-jan-2010',  'DD-MON-YYY') starts returning something more
> sensible than 3010-01-01.

If it can be delivered quickly and it is simple, sure.  But anything
more involved should respect the release schedule.

Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-03-17 14:40:27
Subject: Re: Rectifying wrong Date outputs
Previous:From: Tom LaneDate: 2011-03-17 14:26:30
Subject: Re: Rectifying wrong Date outputs

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group