On Tue, Oct 8, 2013 at 1:34 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Oct 7, 2013 at 12:41 AM, Rushabh Lathia
> <rushabh.lat...@gmail.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?
Do agree with you in certain extent.
But there are already ambiguity when it comes to postgres date module:
For example:
-- Doing select with year field > 4
edb=# select '10-10-22222'::timestamp;
timestamp
---------------------------
Thu Oct 10 00:00:00 22222
(1 row)
edb=# create table test ( a timestamp );
CREATE TABLE
-- When try to insert it throw an error
edb=# insert into test values ('Thu Oct 10 00:00:00 22222');
ERROR: invalid input syntax for type timestamp: "Thu Oct 10 00:00:00 22222"
LINE 1: insert into test values ('Thu Oct 10 00:00:00 22222');
^
Of course user can use the specific format and then this kind of date
can be used.
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 ?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Rushabh Lathia
