From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Piyush Newe <piyush(dot)newe(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(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-21 13:57:57 |
Message-ID: | 20387.1300715877@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 21, 2011 at 6:24 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> Having said that, it's not entirely clear to me what sane behavior is
>>> here. Personally I would expect that an n-Ys format spec would consume
>>> at most n digits from the input. Otherwise how are you going to use
>>> to_date to pick apart strings that don't have any separators?
>> Yeah, seems reasonable.
> On the flip side, what if you want to allow either a two digit year or
> a four digit year? It doesn't seem unreasonable to allow YY to
> emcompass what YYYY would have allowed, unless there's a separate
> notion for 'either YY or YYYY'.
What I was thinking was that YYYY would take either 2 or 4 digits.
Whatever you do here, the year will have to be delimited by a non-digit
for such cases to be parseable.
> I'm OK with that, but again, exactly what rule is Oracle applying here?
Yeah. Hopefully they documented it, and we don't have to try to
reverse-engineer the intention from an undersized set of samples.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-03-21 14:02:17 | Re: Rectifying wrong Date outputs |
Previous Message | Robert Haas | 2011-03-21 13:39:41 | Re: Rectifying wrong Date outputs |