I like this solution because it uses the existing infrastructure of
functional indexes and the ANY capability. It makes perfect sense to me.
So, did this make it to the todo list? It didn't see it there.
Dima, Tom, Stephan, Martin? Is this likely in 7.4?
elein
On Wednesday 19 February 2003 06:44, Tom Lane wrote:
> Dima Tkach <dmitry@openratings.com> writes:
> > And another possibility is to create isnull () operator... but that
> > would have to wait until postgres allows functions with unknown argument
> > types
>
> Actually, we do have that now --- it'd be reasonable to implement such
> a function and operator as taking type ANY. Hm, maybe this is more
> practical than I thought. If we replace the special-purpose NullTest
> expression node by two operators (IS NULL, IS NOT NULL) taking type ANY,
> then you wouldn't have to do any violence to the ScanKeys representation
> to handle these operators as index quals. Rather than adding them to
> pg_opclass for every btree opclass, I'd be inclined to special-case them
> in the planner (they could be a case that special_indexable_operator
> handles) --- with only two to deal with, that doesn't seem impractical.
> Hm, probably only IS NULL need be indexable. We don't index != ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
----------------------------------------------------------------------------------------
elein@varlena.com Database Consulting www.varlena.com
I have always depended on the [QA] of strangers.
