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 14:18:50 |
Message-ID: | 20815.1300717130@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 9:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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 was assuming a slightly more general variant of that - namely, Y,
> YY, or YYY would all accept that many digits, or more; and the result
> of Y with 2, 3, or 4 digits would be the same as if YY, YYY, or YYYY,
> respectively, had been used.
As far as I can see, that would completely destroy the use-case of
trying to parse a string where there's not non-digit delimiters and
so you have to take exactly the specified number of digits, not more.
Why not head in the other direction of allowing fewer digits than
suggested by the format, instead of more?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-03-21 14:25:29 | Re: Planner regression in 9.1: min(x) cannot use partial index with NOT NULL |
Previous Message | Robert Haas | 2011-03-21 14:02:17 | Re: Rectifying wrong Date outputs |