Re: Interval input: usec, msec
От | Tom Lane |
---|---|
Тема | Re: Interval input: usec, msec |
Дата | |
Msg-id | 7654.1180379157@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Interval input: usec, msec (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Interval input: usec, msec
|
Список | 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 по дате отправления: