Re: iscachable settings for datetime functions

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> Hmm. Perhaps the definition for CURRENT_DATE should be recast as a call
> to now() (which happens to return timestamp)

Yes, something like date(now()) might be less subject to breakage as we
monkey around with the semantics of literals and implicit coercions.

BTW, although date(now()) seems okay, I got a rather surprising result
from

template1=# select time(now());
ERROR: Bad time external representation '2001-10-01 18:21:53.49-04'

I haven't dug into this, but surmise that it's trying to do something
involving a conversion to text and back. The less ambiguous form
fails completely:

template1=# select now()::time;
ERROR: Cannot cast type 'timestamp with time zone' to 'time'

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

Well, I'll take responsibility for fixing that, if you want to spread
the blame ;-). It's my fault that those routines are marked cachable
to begin with --- I hadn't dug into which datetime types had "current"
and which didn't, just marked 'em all noncachable on sight.

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

We clearly have got to fix the cachability issue, so I have no objection
to you applying your additional changes if you think they're ready.

regards, tom lane