>
>>Should the plain 'timestamp' type really default to a different type
>>than what all the rest of the timestamp operators prefer?
>
>
> Tell me about it :-(. SQL92 specifies that "timestamp" means "timestamp
> without time zone", but this is an utterly brain-dead default IMHO.
> You can check the PG list archives if you want to see past flamewars
> about the issue. As a member of the losing side I will gracefully
> retire...
>
But is *this* really the issue here?
It seems to me, that everything would work as expected if the planner
tried to cast the *constant* side of the operator to the column type,
and not the other way around - i.e., in this case, it coverts the
original condition into something like
'time::timestamp with timezone < now ()'
if instead it did
'time < now()::timestamp', it would work, (and be able to use the
index), wouldn't it?
Is there some technical difficulty here, making it too complicated to
implement?
Dima