Re: Issue in Behavior of Interval Datatype

select (interval '56:48' minute to second);
result：00:56:48
select (interval '-56:48' minute to second);
result：-56:48:00
select (interval '+56:48' minute to second);
result：56:48:00

When user uses ‘+’ or ‘-‘ symbol, then minute to second range is getting
ignored.

I have checked the code and found that in function DecodeInterval(), for
timezone case (DTK_TZ) it uses INTERVAL_FULL_RANGE irrespective of range
passed by user.

However if use the range passed as argument in function DecodeInterval(),
the result of using ‘+’ or ‘-‘ is same as without using it.

Is there any particular reason for ignoring the range for DTK_TZ case in
DecodeInterval() function?

With Regards,

Amit Kapila

Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> select (interval '56:48' minute to second);
> result$B!'(B00:56:48
> select (interval '-56:48' minute to second);
> result$B!'(B-56:48:00
> select (interval '+56:48' minute to second);
> result$B!'(B56:48:00

> I have checked the code and found that in function DecodeInterval(), for
> timezone case (DTK_TZ) it uses INTERVAL_FULL_RANGE irrespective of range
> passed by user.

> However if use the range passed as argument in function DecodeInterval(),
> the result of using $B!F(B+$B!G(B or $B!F(B-$B!F(B is same as without using it.

> Is there any particular reason for ignoring the range for DTK_TZ case in
> DecodeInterval() function?

I think you are right; this if-block should be exactly like the DTK_TIME
case except for handling the prepended sign. That also raises the
question why it is changing the tmask value returned by DecodeTime.
It seems to be doing exactly the wrong thing there. Test case:

regression=# select (interval '56:48 56:48' );
ERROR: invalid input syntax for type interval: "56:48 56:48"
LINE 1: select (interval '56:48 56:48' );
^
regression=# select (interval '56:48 +56:48' );
interval
----------
56:48:00
(1 row)

The second one fails to fail because an inappropriate tmask value got
included into fmask.

Will fix.

regards, tom lane

From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Saturday, August 04, 2012 1:48 AM
Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> select (interval '56:48' minute to second);
> result$B!'(B00:56:48
> select (interval '-56:48' minute to second);
> result$B!'(B-56:48:00
> select (interval '+56:48' minute to second);
> result$B!'(B56:48:00

> I have checked the code and found that in function DecodeInterval(), for
> timezone case (DTK_TZ) it uses INTERVAL_FULL_RANGE irrespective of range
> passed by user.

> However if use the range passed as argument in function DecodeInterval(),
> the result of using $B!F(B+$B!G(B or $B!F(B-$B!F(B is same as
without using it.

> Is there any particular reason for ignoring the range for DTK_TZ case in
> DecodeInterval() function?

> I think you are right; this if-block should be exactly like the DTK_TIME
> case except for handling the prepended sign. That also raises the
> question why it is changing the tmask value returned by DecodeTime.
> It seems to be doing exactly the wrong thing there. Test case:

> regression=# select (interval '56:48 56:48' );
> ERROR: invalid input syntax for type interval: "56:48 56:48"
> LINE 1: select (interval '56:48 56:48' );
^
> regression=# select (interval '56:48 +56:48' );
> interval
> ----------
> 56:48:00
> (1 row)

> The second one fails to fail because an inappropriate tmask value got
>included into fmask.

Yes, this is right that tmask need not be changed, also one more thing I
have noticed that
in file Interval.c also there is a function DecodeInterval() which is
currently little different
from DecodeInterval() in datetime.c for DTK_TZ case.
For example Assert check is commented.
Why the Assert check is commented out there?
May be due to some defect, but I am not able to think the reason for same.

Shouldn't we make this change (don't change tmask in case of DTK_TZ) in
Interval.c?

>Will fix.

Thank you very much.

With Regards,
Amit Kapila.

Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> Yes, this is right that tmask need not be changed, also one more thing I
> have noticed that
> in file Interval.c also there is a function DecodeInterval() which is
> currently little different
> from DecodeInterval() in datetime.c for DTK_TZ case.
> For example Assert check is commented.
> Why the Assert check is commented out there?

Assert doesn't work in client-side code.

More generally, nobody is maintaining ecpg's copy of the datetime code,
and that's been true for a very long time. I'm not personally
interested in trying to re-sync that copy. It would be more useful to
figure out a way to get rid of it. There have been past discussions of
how we could make a single copy of the code work in both backend and
frontend contexts, but the frontend environment is so impoverished by
comparison (no Assert, no elog, no palloc) that it hasn't looked like an
attractive idea. It's also fairly unclear whether anyone is actually
using ecpg's client-side datetime support, which means there's little
motivation to put a lot of work into it.

regards, tom lane

On Sat, Aug 04, 2012 at 12:11:56PM -0400, Tom Lane wrote:
> More generally, nobody is maintaining ecpg's copy of the datetime code,
> and that's been true for a very long time. I'm not personally

Well, maintaining as in fixing bugs I do as I find time. Maintaining as in
keeping in sync with the backend nobody does, you're right. However, as long as
the code works and the internal data representation isn't changed or used,
that's not really a problem.

> interested in trying to re-sync that copy. It would be more useful to
> figure out a way to get rid of it. There have been past discussions of

+1

> how we could make a single copy of the code work in both backend and
> frontend contexts, but the frontend environment is so impoverished by
> comparison (no Assert, no elog, no palloc) that it hasn't looked like an
> attractive idea. It's also fairly unclear whether anyone is actually
> using ecpg's client-side datetime support, which means there's little
> motivation to put a lot of work into it.

This is an interesting question. I used to think that even ecpg is not used
very often anymore but I keep running into large scale usages from time to
time. And at least some do use pgtypeslib, too.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL