Chapman Flack <chap@anastigmatix.net> writes:
> On 09/02/19 00:29, Tom Lane wrote:
>> If we ever do make ObjectAddress.objectSubId mean something for types,
>> I'd expect --- based on the precedent of relation columns --- that it'd
>> specify a column number for a column of a composite type. There are
>> fairly obvious use-cases for that, such as allowing a DROP of a column
>> type to not propagate to the whole composite type.
> Could you give an illustration to make sure I'm following?
Hm, apparently we already do handle that in some way, because
this works:
regression=# create type myenum as enum ('red', 'black');
CREATE TYPE
regression=# create type mycomposite as (f1 int, f2 myenum, f3 text);
CREATE TYPE
regression=# drop type myenum;
ERROR: cannot drop type myenum because other objects depend on it
DETAIL: column f2 of composite type mycomposite depends on type myenum
HINT: Use DROP ... CASCADE to drop the dependent objects too.
regression=# drop type myenum cascade;
NOTICE: drop cascades to column f2 of composite type mycomposite
DROP TYPE
regression=# \d mycomposite
Composite type "public.mycomposite"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
f1 | integer | | |
f3 | text | | |
I'm too lazy to go check, but I suspect that the representation
of this situation in pg_depend makes use of a dependency for a
column of the relation associated with the mycomposite type,
so that the entry having nonzero objsubid has classid pg_class
not classid pg_type.
Nonetheless, I'd be pretty hesitant to allow somebody to use
objsubid with some entirely different meaning for types. That
seems certain to lead to confusion and bugs.
regards, tom lane