Re: insert throw error when year field len > 4 for timestamptz datatype - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: insert throw error when year field len > 4 for timestamptz datatype
Date
Msg-id 20131008130537.GH22450@momjian.us
Whole thread Raw
In response to Re: insert throw error when year field len > 4 for timestamptz datatype  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: insert throw error when year field len > 4 for timestamptz datatype  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Oct  8, 2013 at 05:08:17PM +0530, Rushabh Lathia wrote:
>     This
>     might be a case where throwing an error is actually better than trying
>     to make sense of the input.
> 
>     I don't feel super-strongly about this, but I offer it as a question
>     for reflection.
> 
> 
> 
> At the same time I do agree fixing this kind of issue in postgres datetime
> module 
> is bit difficult without some assumption. Personally I feel patch do add some
> value but not fully compatible with all kind of year field format.
> 
> Bruce,
> 
> Do you have any thought/suggestion ?

I think Robert is asking the right question:  Is it better to accept
5-digit years, or throw an error?  Doing anything new with 6-digit years
is going to break the much more common use of YMD or HMS.

The timestamp data type only supports values to year 294276, so the full
6-digit range isn't even supported.  ('DATE' does go higher.)

The entire date/time processing allows imprecise input, so throwing an
error on clear 5-digit years seems wrong.  Basically, we have gone down
the road of interpreting date/time input liberally, so throwing an error
on a clear 5-digit year seems odd.

On the other hand, this has never come up before because no one cared
about 5-digit years, so you could argue that 5-digit years require
precise specification, which would favor throwing an error.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: KONDO Mitsumasa
Date:
Subject: Re: Compression of full-page-writes
Next
From: KONDO Mitsumasa
Date:
Subject: Re: Compression of full-page-writes