mikeo <[EMAIL PROTECTED]> writes:
>>> we've run into a problem after having deleted the line type.
>>> when we attempt to query a table by column which is defined as float8
>>> we get this error:
>>>
>>> select * from test1 where tfap_id = 49232;
>>> ERROR: Unable to locate type oid 628 in catalog
Interesting. I get:
bust=# create table foo (f1 int, f2 float8);
CREATE
bust=# insert into foo values(1,2.5);
INSERT 148298 1
bust=# select * from foo;
f1 | f2
----+-----
1 | 2.5
(1 row)
bust=# drop type line;
DROP
bust=# select * from foo;
f1 | f2
----+-----
1 | 2.5
(1 row)
bust=# select * from foo where f2 = 2.5;
f1 | f2
----+-----
1 | 2.5
(1 row)
bust=# select * from foo where f2 < 3;
f1 | f2
----+-----
1 | 2.5
(1 row)
bust=# select * from foo where f2 = 3;
ERROR: Unable to locate type oid 628 in catalog
It looks to me like the problem appears when the parser has to resolve
an ambiguous operator. (Since there isn't a "float8 = int" operator,
this last case requires some smarts to figure out what to do.)
Presumably there is a line = line operator still in the system, and
it doesn't surprise me a whole lot that this error would pop up if the
parser had occasion to scan through the '=' operators looking for a
possible match and came across that one. Let's see:
bust=# select * from pg_operator where oprname = '=' and
bust-# (oprleft = 628 or oprright = 628);
oprname | oprowner | oprprec | oprkind | oprisleft | oprcanhash | oprleft | oprright
| oprresult | oprcom | oprnegate | oprlsortop | oprrsortop | oprcode | oprrest |
oprjoin
---------+----------+---------+---------+-----------+------------+---------+----------+-----------+--------+-----------+------------+------------+---------+---------+-----------
= | 256 | 0 | b | t | f | 628 | 628
| 16 | 1616 | 0 | 0 | 0 | line_eq | eqsel |
eqjoinsel
(1 row)
bust=# delete from pg_operator where oprname = '=' and
bust-# (oprleft = 628 or oprright = 628);
DELETE 1
bust=# select * from foo where f2 = 3;
f1 | f2
----+----
(0 rows)
Yup, looks like that's the problem.
It's probably not good that DROP TYPE only zaps the pg_type entry and
doesn't go hunting for stuff that depends on it. In the meantime you
might want to do
delete from pg_operator where oprleft = 628 or oprright = 628;
and perhaps something similar for pg_proc, although name collisions for
functions are probably less of a problem there.
regards, tom lane
