|
10 | 10 | * |
11 | 11 | * |
12 | 12 | * IDENTIFICATION |
13 | | - * $PostgreSQL: pgsql/src/backend/utils/adt/nabstime.c,v 1.164 2010/02/26 02:01:09 momjian Exp $ |
| 13 | + * $PostgreSQL: pgsql/src/backend/utils/adt/nabstime.c,v 1.165 2010/08/03 16:31:02 tgl Exp $ |
14 | 14 | * |
15 | 15 | *------------------------------------------------------------------------- |
16 | 16 | */ |
@@ -1155,9 +1155,22 @@ tintervalsame(PG_FUNCTION_ARGS) |
1155 | 1155 | /* |
1156 | 1156 | * tinterval comparison routines |
1157 | 1157 | * |
1158 | | - * Note: comparison is based on the lengths of the tintervals, not on |
1159 | | - * endpoint value.This is pretty bogus, but since it's only a legacy |
1160 | | - * datatype I'm not going to propose changing it. |
| 1158 | + * Note: comparison is based only on the lengths of the tintervals, not on |
| 1159 | + * endpoint values (as long as they're not INVALID). This is pretty bogus, |
| 1160 | + * but since it's only a legacy datatype, we're not going to change it. |
| 1161 | + * |
| 1162 | + * Some other bogus things that won't be changed for compatibility reasons: |
| 1163 | + * 1. The interval length computations overflow at 2^31 seconds, causing |
| 1164 | + * intervals longer than that to sort oddly compared to those shorter. |
| 1165 | + * 2. infinity and minus infinity (NOEND_ABSTIME and NOSTART_ABSTIME) are |
| 1166 | + * just ordinary integers. Since this code doesn't handle them specially, |
| 1167 | + * it's possible for [a b] to be considered longer than [c infinity] for |
| 1168 | + * finite abstimes a, b, c. In combination with the previous point, the |
| 1169 | + * interval [-infinity infinity] is treated as being shorter than many finite |
| 1170 | + * intervals :-( |
| 1171 | + * |
| 1172 | + * If tinterval is ever reimplemented atop timestamp, it'd be good to give |
| 1173 | + * some consideration to avoiding these problems. |
1161 | 1174 | */ |
1162 | 1175 | staticint |
1163 | 1176 | tinterval_cmp_internal(TimeIntervala,TimeIntervalb) |
|