Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> ... I don't really see any theorical need for opclass if
> it's not for indexing.
Well, if we were starting from a green field, we might design it
differently, but I see little point in changing the system structure
now that it's established. You need *some* representation for the
properties and relationships of sets of operators, and so far the btree
and hash index opclasses have matched up quite well with what other
parts of the system wanted to know; so why duplicate that information?
> My formulation was "outright wrong", as you would say, but I hope to
> have explained a little better what I'm on: there's not enough direct
> semantic information concerning operators for the planner to take full
> profit out if it. It this assertion more true?
Not really. I can see an argument that there might be something we wish
to know about groups of operators that can't reasonably be expressed
within the opclass infrastructure, and in that situation maybe it would
be time to invent something else. But it hasn't come up yet.
Note that new properties of *individual* operators would just be handled
by adding columns to pg_operator, and aren't really relevant to this
discussion.
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
