Martijn van Oosterhout <klep...@svana.org> writes:
> On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
>> Now that specialized hard-coding "+"/"-" in source seems unacceptable,
>> I would like to hear how to handle this. Is there any better than
>> introducing new mechanism such like opclass?
> I imagine it would be easiest to add these operators to the existing
> opclass infrastructure. Although it didn't start that way, the opclass
> structure is being more and more used to declare the semantics of a
> type. Btree operator classes are for *ordered* types, which seems to be
> the only case you can expect to work here.
> Currently the btree operator classes have only one support function, so
> it would seem than the easiest approach would be to declare two new
> support functions for add() and subtract().
Yeah, that was pretty much the same line of thought I had. The main
disadvantage seems to be two more catalog lookups per index to fill in
support function entries that won't ever be used (at least not by the
index machinery). However, I think we cache that stuff already inside
relcache.c, so it might be insignificant.
The real question is whether it's time to bite the bullet and stop
overloading the opclass infrastructure for semantics-declaration
purposes. Are there any other foreseeable cases where we are going
to need to add operator knowledge of this sort?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
