aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2012-02-09 12:22:21 -0500
committerRobert Haas <rhaas@postgresql.org>2012-02-09 12:24:36 -0500
commitd429ebe347a5f1404cc3c50234e1c93f8db2bb53 (patch)
tree4e6fb359ffbe97a3485db3490241f54a3c9c27f3
parent6656588575abd13016989be1a276b1b60be49b69 (diff)
downloadpostgresql-d429ebe347a5f1404cc3c50234e1c93f8db2bb53.tar.gz
postgresql-d429ebe347a5f1404cc3c50234e1c93f8db2bb53.zip
Add a comment to AdjustIntervalForTypmod to reduce chance of future bugs.
It's not entirely evident how the logic here relates to the interval_transform function, so let's clue people in that they need to check that if the rules change.
-rw-r--r--src/backend/utils/adt/timestamp.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c
index 12af7f69f69..db434dcb3cc 100644
--- a/src/backend/utils/adt/timestamp.c
+++ b/src/backend/utils/adt/timestamp.c
@@ -1069,7 +1069,8 @@ AdjustIntervalForTypmod(Interval *interval, int32 typmod)
* nonzero "month" field. However that seems a bit pointless when we
* can't do it consistently. (We cannot enforce a range limit on the
* highest expected field, since we do not have any equivalent of
- * SQL's <interval leading field precision>.)
+ * SQL's <interval leading field precision>.) If we ever decide to
+ * revisit this, interval_transform will likely requite adjusting.
*
* Note: before PG 8.4 we interpreted a limited set of fields as
* actually causing a "modulo" operation on a given value, potentially