Re: insert throw error when year field len > 4 for timestamptz datatype
От | Rushabh Lathia |
---|---|
Тема | Re: insert throw error when year field len > 4 for timestamptz datatype |
Дата | |
Msg-id | CAGPqQf3XwWC_4fhiNz_G6EcvPs_OV3k2pe4-aJ1dg4iyY+f_Dw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: insert throw error when year field len > 4 for timestamptz datatype (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: insert throw error when year field len > 4 for
timestamptz datatype
|
Список | pgsql-hackers |
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:
Yes, earlier in the thread the original patch poster questioned whetherOn 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.
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
Вложения
В списке pgsql-hackers по дате отправления: