Re: insert throw error when year field len > 4 for timestamptz datatype

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Haribabu kommi <haribabu(dot)kommi(at)huawei(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: insert throw error when year field len > 4 for timestamptz datatype
Date: 2013-10-07 20:04:15
Message-ID: CA+TgmoYSMQBr=h-MdxnhsnomsqYLHq+hw+6WNQCjjRkoHr6u7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 7, 2013 at 12:41 AM, Rushabh Lathia
<rushabh(dot)lathia(at)gmail(dot)com> wrote:
> Hmm right it has some inconsistency when year length is 6. But the patch
> is based on assumption that 5-digit number is a year, because YMD and HMS
> require at least six digits. Now Year with 6-digit number its getting
> conflict with
> YMD and HMS, that the reason its ending up with error. So with patch
> approach
> that's an expected behaviour for me.
>
> I spent good amount of time on thinking how we can improve the behaviour, or
> how can be change the assumption about the year field, YMD and HMS. At
> current point of time it seems difficult to me because postgres date module
> is tightly build with few assumption and changing that may lead to big
> project.
> Not sure but personally I feel that patch which was submitted earlier was
> definitely good improvement.
>
> Any other suggestion or thought for improvement ?

I'm not entirely convinced that this patch is heading in the right
direction. The thing is, it lets you use 5-digit years always and
longer years only in some contexts. So I'm not sure this is really
good enough for unambiguous date input. If you want that, you should
probably be using trusty YYYYYYYYYYY-MM-DD format. But if you don't
need that, then isn't a five-digit year most likely a typo? 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-10-07 20:06:59 Re: pgbench progress report improvements - split 3 v2 - A
Previous Message Robert Haas 2013-10-07 19:57:46 Re: [COMMITTERS] pgsql: Add DISCARD SEQUENCES command.