Re: Interval input: usec, msec

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Interval input: usec, msec
Date: 2007-05-28 19:05:57
Message-ID: 7654.1180379157@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2007-05-28 19:13:21 boolean <=> text explicit casts
Previous Message Greg Smith 2007-05-28 19:01:10 Re: COPY-able csv log outputs