Re: Rectifying wrong Date outputs
От | Robert Haas |
---|---|
Тема | Re: Rectifying wrong Date outputs |
Дата | |
Msg-id | AANLkTimiSPRE6affMZWZ3ubzNFA_RpjPb5ZP8gE4qXU2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rectifying wrong Date outputs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Rectifying wrong Date outputs
|
Список | pgsql-hackers |
On Mon, Mar 21, 2011 at 9:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Mar 21, 2011 at 6:24 AM, Heikki Linnakangas >> <heikki.linnakangas@enterprisedb.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 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: