Re: iscachable settings for datetime functions

> I've been looking at the iscachable changes you committed recently,
> and I think a lot of them need to be adjusted still.

Sure. Me too ;)

I changed some for the areas within which I was working, and it did
occur to me that (as you mention below) anything affected as a side
effect of some other system setting such as default time zone will need
to be non-cachable.

> 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?

Right. Some can be cachable (e.g. timestamp, date, and time do not have
associated time zones). I'll look at the other ones asap.

> 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

Hmm. Perhaps the definition for CURRENT_DATE should be recast as a call
to now() (which happens to return timestamp) or perhaps I should have
another function call. In any case, I agree that text_date() needs to be
noncachable.

> 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.

I stayed away from changes to abstime, since I wasn't working with that
type and wanted to limit collateral damage to the other big changes I
had made.

I'll propose that we postpone beta until after Marc, Vince, and
*everyone* agree that the servers are running smoothly (a step already
suggested by others). And I'll also ask that we allow my latest
date/time changes and the above catalog fixups, which may come about
before the servers settle down.

- Thomas