Re: Interval support for Postgres

On Friday 29 April 2005 10:01, Kris Jurka wrote:
> On Sat, 23 Apr 2005, Oliver Siegmar wrote:
> > The applied patch contains all modifications from the last one
> > (pgjdbc_interval2.diff) as well as a replacement for the regular
> > expression code.
>
> Here's my version of it.  Changes:
>  - Always use noniso format for sending intervals to the backend.
>    This makes it possible to support a seconds field of 90.  Also
>    don't need to worry about signs of fields.

Sounds reasonable. But I'm not sure if we should support "oversized" values -
I see no requirement for it, and it adds a lot of possible trouble.

Anyway...I have used the + concatination (in getValue()) knowingly, because
JDK < 5.0 compiles that to StringBuffer and JDK 5.0 to StringBuilder
automatically. The usage of StringBuffer and StringBuilder makes only sense
if the string isn't built as a one-liner.

> My one remaining question is about the roll function.  What is the purpose
> of roll, don't we want add?

a) because the database doesn't return "oversized" values - so it doesn't
matter using add() or roll()

b) because add() is a beast. Consider the following simple example:

---------------------------------------------------------------------------
01: Calendar cal1 = Calendar.getInstance();
02: Calendar cal2 = (Calendar)cal1.clone();
03:
04: System.out.println(cal1.equals(cal2)); // returns true, of course
05:
06: cal1.add(Calendar.MONTH, -4);
07: cal1.add(Calendar.DAY_OF_WEEK_IN_MONTH, 20);
08:
09: cal1.add(Calendar.MONTH, 4);
10: cal1.add(Calendar.DAY_OF_WEEK_IN_MONTH, -20);
11:
12: System.out.println(cal1.equals(cal2)); // returns false
---------------------------------------------------------------------------

But if you twist line 9 and 10 - everything is ok. If you use add() you have
to use the inverse order if you want to "roll" backwards, again. I see no way
to get a PGInterval.add() method acting symmetric.

> Ignoring carryover seems like a mistake.

Not if all values are "in range". The method name roll() won't be
misunderstood, I think.

> Also in the roll method the milliseconds calculation should round the
> value so 0.6006 seconds becomes 601 milliseconds.

Why? When is the current implementation doing wrong?


Oliver