I first thought that Andy Lewis' recent complaint might be a GIST
problem, but it's not. Observe the following:
regression=# create domain mytype as int;
CREATE DOMAIN
regression=# create table foo (f1 int, f2 mytype);
CREATE TABLE
regression=# drop type mytype cascade;
NOTICE: Drop cascades to table foo column f2
DROP TYPE
-- so far so good, but:
regression=# insert into foo values(1);
ERROR: Unable to look up type id 703560
regression=# update foo set f1=1;
ERROR: Unable to look up type id 703560
The failure occurs in ExecTypeFromTL(), which is required to build a
tuple descriptor for the output tuple of each plan node. In these
cases, there is an output column (which will be NULL) for the dropped
column foo.f2 ... so the code goes off to get the type properties.
Oops.
Fortunately, we are not up the proverbial creek with no paddle, because
the only things we really need to know about the dropped column are its
typlen and typalign --- which just happen to still be recorded in
pg_attribute.attlen and attalign. (Let's hear it for denormalization.)
It will take a little bit of code rearrangement to make that information
available to ExecTypeFromTL(), but I see no alternative.
I am thinking that it might be a good idea for ALTER TABLE DROP COLUMN
to reset atttypid to zero in the dropped column's pg_attribute row.
This would help catch any other places that are depending on a dropped
column's atttypid to still be valid. On the other hand, it would
possibly confuse applications that are looking at pg_attribute.
Comments anyone?
regards, tom lane
