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  (Bruce Momjian <bruce@momjian.us>)
Список 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:
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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: Custom Plan node