Re: Interval input: usec, msec - Mailing list pgsql-patches

From Tom Lane
Subject Re: Interval input: usec, msec
Date
Msg-id 7654.1180379157@sss.pgh.pa.us
Whole thread Raw
In response to Re: Interval input: usec, msec  (Neil Conway <neilc@samurai.com>)
Responses Re: Interval input: usec, msec  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> On Mon, 2007-28-05 at 10:50 -0400, Tom Lane wrote:
>> I'd argue that it's an oversight.  I don't have a problem with adding up
>> the values of units that really translate to the same thing (eg,
>> '1 week 1 day' -> '8 days'), but I think '1 second 2 second' should
>> be rejected because it's almost certainly user error.

> I don't see why "1 week 1 week" is any less likely to be user error than
> "1 second 1 second".

Right.  I guess you misunderstood me: I was arguing for rejecting double
occurrences of the same unit name, but not occurrences of different unit
names that we happen to map into the same interval field internally.
IOW the behavior ought to be predictable without knowing which unit
names map to the same field.

>    * add tmask bits for msec, usec (I reordered the #defines to keep
>      them logically contiguous, but AFAICS this isn't necessary)

I forget --- are the tmask bits used in stored typmod values for
intervals?  It'd probably be best not to change the meanings of typmod
bits, since those are visible to client code if it wants to look.

> BTW, does anyone know why a few of the regression tests (tinterval,
> point, geometry, etc.) explicitly disable and then re-enable GEQO?

Hmmm ... if you check the cvs history for those tests you might find
some evidence.

            regards, tom lane

pgsql-patches by date:

Previous
From: Greg Smith
Date:
Subject: Re: COPY-able csv log outputs
Next
From: Neil Conway
Date:
Subject: boolean <=> text explicit casts