On Wed, Dec 13, 2006 at 07:28:20PM -0500, Tom Lane wrote: > Some more thought about that yielded what might or might not be a good > idea: why not just collapse all the members of a "class group" into one > opclass? In other words, not make a distinction between groups and > individual opclasses? So for example, int2_ops int4_ops and int8_ops > would all collapse into one big opclass.
I think it may be useful to maintain the distinction between groups and classes for users, because at that level the whole concept is easier to understand. Dropping and recreating operator classes is easier to handle than playing strange tricks with ALTER OPERATOR CLASS GROUP. And probably easier to get right/harder to screw up. How the backend implements it may be easier as one single large opclass. Essentially the operater class table becomes merely a placeholder for the name (maybe also aliases?), which can still be used in index declarations, but is never used by the backend otherwise. That would preserve backward compatability while still allowing all the benefits. BTW, in some aspects this resembles some of the changes needed for SQL collate support. There also I tried to merge operator classes into something larger. However, there the point was that the group becomes a common pathkey identifier for all the underlying types, which is not in your proposal. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature