From: | Dima Tkach <dmitry(at)openratings(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Bierman <bierman(at)apple(dot)com>, pgsql-novice(at)postgresql(dot)org |
Subject: | Re: why doesn't an index help my simple query? |
Date: | 2003-05-31 17:46:24 |
Message-ID: | 3ED8EA70.20006@openratings.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
>
>>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
From | Date | Subject | |
---|---|---|---|
Next Message | Herbie McDuck | 2003-06-01 09:16:12 | Me again..nOOb alert |
Previous Message | Frank Bax | 2003-05-31 17:30:59 | Re: Examples of accessing postgresql with scripts? |