Re: Interval input: usec, msec

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".

> Does your patch allow '1 millisec 2 microsec', which should be allowed
> by this argument?

Yes: in order to allow the above input, the straightforward coding also
allows "1 second 2 second".

> I suspect that to make it work unsurprisingly, we'd
> need to allocate a distinct tmask bit to each logically distinct unit.

Okay, attached is a patch that does this. To summarize, the changes are:

   * add tmask bits for msec, usec (I reordered the #defines to keep
     them logically contiguous, but AFAICS this isn't necessary)
   * if the user specifies multiple instances of usec, msec, or sec,
     reject as invalid input
   * if the user specifies a fractional second ("5.5 seconds"), also
     consider that to be millisecond and microsecond input from the
     POV of rejecting duplicate units. So "5.5 seconds 1 millisecond"
     will be rejected.

Docs and regression tests updated. If people are happy with the above
behavior, I'll commit this to HEAD shortly (today/tomorrow), and perhaps
backport it: not accepting "1 msec" and similar inputs is a clear bug,
IMHO.

BTW, does anyone know why a few of the regression tests (tinterval,
point, geometry, etc.) explicitly disable and then re-enable GEQO?
AFAICS the regression tests are just doing fairly routine two-table
joins, so GEQO will not be invoked with a sane configuration anyway.

-Neil