Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 2010/12/27 Robert Haas <robertmhaas@gmail.com>:
>> As far as window functions go, we clearly need some kind of type
>> interface feature, but I am unclear whether we should sandwhich it
>> into the btree opclass machinery or whether it might be better to
>> create a whole separate concept just for this purpose.
> I believe we should use btree opclass machinery to represent
> add/subtract interfaces because in the RANGE case you eventually need
> add constant to value and compare it with some boundary by using
> btree. Or, btree operator set would be shared in the type interface
> machinery. We will want to avoid duplication between them.
The thing is, these operators have no arguable application in the
context of actual btree index searches. We could certainly stick them
into pg_amop anyway, using a third amoppurpose category to distinguish
them from searchable or orderable operators. But I share Robert's
discomfort with this --- it's unarguably an abuse of the original
intention of operator classes.
OTOH, operator classes are what we've got to represent the abstract
semantics of operators, and it's not real clear to me what we'd gain by
inventing an independent catalog structure to do more or less the same
sort of thing. One good reason *not* to do that is it'll represent even
more stuff that has to be cached during backend startup.
[ thinks for a bit... ] One reason for having a different structure
would be if we needed to represent abstract semantics for some operators
that couldn't be associated with a btree opclass. This is clearly not
an issue for what RANGE needs, since anything you can order by will
surely have a btree opclass for that, and in fact we probably need to
tie those operators to specific orderings if a datatype has more than
one sort ordering. But maybe there could be some other situation where
we'd need to describe operator behavior for a datatype independently of
any sort ordering. Can anyone come up with a plausible example?
regards, tom lane