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