Andrey Borodin <x4mmm@yandex-team.ru> writes:
> I was looking for a way to correctly drop compress\decompress functions from opclasses.
Making a new opclass seems like a pretty grotty answer; it won't
help existing installations.
I think what you need is to undo opclasscmds.c's decision that the
dependencies should be INTERNAL. I tried this:
regression=# ALTER OPERATOR FAMILY gist_seg_ops USING gist drop function 3 (seg);
ERROR: cannot drop function 3 (seg, seg) of operator family gist_seg_ops for access method gist:
gseg_compress(internal)because operator class gist_seg_ops for access method gist requires it
regression=# update pg_depend set deptype = 'a' where classid = 'pg_amproc'::regclass and objid = (select objid from
pg_dependwhere classid = 'pg_amproc'::regclass and refclassid = 'pg_proc'::regclass and refobjid =
'gseg_compress(internal)'::regprocedure)and refclassid = 'pg_opclass'::regclass and deptype = 'i';
UPDATE 1
regression=# ALTER OPERATOR FAMILY gist_seg_ops USING gist drop function 3 (seg);
ALTER OPERATOR FAMILY
For safety, that update requires a bunch more pg_catalog
schema-qualification than I bothered with, but you get the idea.
I'm not sure if needing this hack indicates that we need more ALTER
OPERATOR CLASS/FAMILY syntax to provide a less hacky way of solving
the problem. The idea of removing core entries of an opclass has
never come up before, and I'm not sure it would ever come up again.
If we come across another use-case maybe then would be the time to
fix it more cleanly.
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