| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | adrian(dot)klaver(at)aklaver(dot)com, frazer(at)frazermclean(dot)co(dot)uk, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Unexpected interval comparison |
| Date: | 2017-04-03 15:35:25 |
| Message-ID: | 23053.1491233725@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Ok, the attached patch changes the result type of
> interval_cmp_value from TimeOffset(=int64) to new 128 bit
> LinearInterval. The value is hidden under the functions
> interval_eq/ge.../cmp and all other stuff seems to use the
> functions.
Looking at this now ... why isn't the INT64_AU32 macro just
#define INT64_AU32(i64) ((i64) >> 32)
? The business with subtracting and re-adding 1 seems unnecessary, and it
also creates a risk of overflow with the minimum possible int64 value.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2017-04-03 16:10:32 | Re: PostgreSQL and Kubernetes |
| Previous Message | Merlin Moncure | 2017-04-03 13:51:00 | Re: My humble tribute to psql -- usql v0.5.0 |