I've been looking at the iscachable changes you committed recently,
and I think a lot of them need to be adjusted still.
One consideration I hadn't thought of recently (though I think we did
take it into account for the 7.0 release) is that any function whose
output varies depending on the TimeZone variable has to be marked
noncachable. This certainly means that some (all?) of the datetime
output functions need to be noncachable. I am wondering also if any
of the type conversion functions depend on TimeZone --- for example,
what are the rules for conversion between timestamptz and timestamp?
The functions that convert between type TEXT and the datetime types
need to be treated the same as the corresponding I/O conversion
functions. For example, text_date is currently marked cachable
which is wrong --- as evidenced by the fact that CURRENT_DATE is
folded prematurely:
regression=# create table foo (f1 date default current_date);
CREATE
regression=# \d foo
Table "foo"
Column | Type | Modifiers
--------+------+----------------------------
f1 | date | default '2001-09-29'::date
The two single-parameter age() functions need to be noncachable since
they depend on today's date. I also suspect that their implementation
should be revised: writing 'today' with no qualifier exposes you to
premature constant folding. Probably
select age(current_date::timestamp, $1)
(or ::timestamptz respectively) would work better.
Why are only some of the date_part functions cachable? Is this a
timezone dependency issue, or just an oversight?
Surely the abstime comparison functions must be cachable (if they can't
be, then indexes on abstime are nonsensical...). Ditto for all other
within-type comparison functions.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
