Обсуждение: Another OPERATOR bug??

In our test environment, we performed the following set of commands (given
that the in/out functions already exist):

CREATE TYPE testtype (   internallength = 4,   input = test_in,   output = test_out
);

CREATE FUNCTION test_function(testtype, testtype)   RETURNS bool   AS '/usr/local/pgsql/types/bitset.so'   LANGUAGE
'c';


CREATE OPERATOR ^^^ (   leftarg = testtype,   rightarg = testtype,   procedure = test_function
);

DROP TYPE testtype;

Here, we've just dropped the testttype that the operator ^^^ uses.  This
does not cause the operator to be deleted, it simply reverts its left and
right args to 'NONE'.

So, we're left with an operator with two NONE arguments (and returns NONE),
so we now try to drop this operator:

DROP OPERATOR ^^^ (NONE, NONE);

This fails with:

ERROR: parser: parse error at or near "NONE"

DROP OPERATOR ^^^ (none, none);

Also fails.

How do we go about dropping the now invalid operator???

Chris

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Here, we've just dropped the testttype that the operator ^^^ uses.  This
> does not cause the operator to be deleted, it simply reverts its left and
> right args to 'NONE'.

No, it doesn't "revert the types to NONE", because there isn't any such
type as NONE.  What you've got is an operator whose argument types refer
to a nonexistent type OID.  You won't be able to drop it with DROP
OPERATOR because you can't name the now-gone type.

There's been talk of having interlocks that prevent you from dropping
a still-referenced type, function, etc, but they're not there now.
I'd suggest cleaning up by executing commands like
delete from pg_operator where oprleft = oid-of-vanished-type

(if you don't know what the type's oid was, a little crosschecking of
pg_operator against pg_type will tell you).
        regards, tom lane