Postgres Pro
Downloads
Home   >   mailing lists

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

From Rushabh Lathia
Subject Re: insert throw error when year field len > 4 for timestamptz datatype
Date
Msg-id CAGPqQf3XwWC_4fhiNz_G6EcvPs_OV3k2pe4-aJ1dg4iyY+f_Dw@mail.gmail.com
Whole thread Raw
In response to Re: insert throw error when year field len > 4 for timestamptz datatype  (Bruce Momjian <bruce@momjian.us>)
Responses Re: insert throw error when year field len > 4 for timestamptz datatype
List pgsql-hackers
Tree view
Thanks Bruce.

Yes for me main problem was to make assumption that a 5-digit number is a year,
as was bit worried about side effect of that assumption in the date/time module. I
did tested patch shared by you with various test and so far it looks good to me.

I would like reviewer to review/test the patch and share his comments.

Attaching the git patch again with this mail.

Assigning to Reviewer.

Regards,
Rushabh


On Wed, Oct 2, 2013 at 9:34 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Oct  2, 2013 at 11:00:30AM -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 7:52 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > On Fri, Sep 27, 2013 at 10:42:17AM +0000, Haribabu kommi wrote:
> >> If the changes are very high to deal all scenarios,
> >>
> >> I feel it is better do it only in scenarios where the use cases needs it, until
> >> it is not confusing users.
> >>
> >> The rest can be documented.
> >>
> >> Any other opinions/suggestions welcome.
> >
> > I have reviewed this patch and it is good.  The problem is guessing if a
> > number with 5+ digits is YMD, HMS, or a year.  I have created a modified
> > patch, attached, assumes a 5-digit number is a year, because YMD and HMS
> > require at least six digits, and used your date/time test to control the
> > other cases.  I also added a few more regression tests.
>
> In an ideal world the interpretation of the tokens wouldn't depend on
> the order in which they appear.  But we don't live in an ideal world,
> so maybe this is fine.

Yes, earlier in the thread the original patch poster questioned whether
he was going in the right direction, given the unusual hacks needed, but
such hacks are standard operating procedure for date/time stuff.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +



--
Rushabh Lathia
Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Next
From: Kohei KaiGai
Date:
Subject: Re: Custom Plan node