On Thu, Dec 14, 2006 at 08:31:59PM -0500, Tom Lane wrote:
> > 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.
>
> To represent this cleanly in the catalogs, we'd probably want nominally
> stand-alone opclasses to belong to implicitly created single-member
> groups, because the individual entries in pg_amop and pg_amproc are
> always going to be shown as belonging to groups --- the membership
> hierarchy above is only interesting in pg_depends, not for index
> operations. I think that's about the same thing you're saying here.
I think we're on the same page. I thought of another motivation also:
protections/permissions. We don't currently allow people to mess with
definitions needed by system catalogs, so you don't want to allow users
to mess with the btree(int4) class, but you want to allow them to
modify the group as a whole to add new things and remove things they've
added.
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.