Postgres 复合类型 drop cascade 仅删除依赖列答案

【问题标题】：Postgres composite type drop cascade removes dependant columns onlyPostgres 复合类型 drop cascade 仅删除依赖列
【发布时间】：2016-05-04 13:23:12
【问题描述】：

（使用下面的示例代码...）我一直很困惑地执行一些（可重新执行的）脚本（在源代码仓库中保存/版本控制数据库逻辑）说明确定义的列 foo.foo_b 不存在，尽管它已在脚本中成功执行。

显示此内容的测试代码：

-- foo.sql type script
drop type if exists foo cascade ;
create type foo as (
    --foo_b bar,  -- (a) not there in first script version
    foo_c char
) ;

-- bar.sql type script
drop type if exists bar cascade ;
create type bar as (
    bar_i int
) ;

-- simple sample code that may cause the strange error

select (null::foo).* ;
--select (null::foo).foo_b ;  -- (a) not there in first script version

执行带有(a) 注释的脚本（原样）：

(0 rows affected)
(0 rows affected)
(0 rows affected)
(0 rows affected)
 foo_c
 -----
 -
(0 rows affected)

在使用我们新的foo_b 列的情况下执行脚本（从上面的2 个(a) 标记的行中删除了注释-- 前缀）：

(0 rows affected)
(0 rows affected)
(0 rows affected)
(0 rows affected)
 foo_c
 -----
 -
(0 rows affected)
ERROR: column "foo_b" not found in data type foo
  Position: 9

我原来的sql不一样，居然引起了同一个原因的另一个错误：

select row( null::bar, 'xxx' )

ERROR: cannot cast type record to foo
  Detail: Input has too many columns.
  Position: 7818

【问题讨论】：

如果bar 是table（或它的隐式创建类型），则同样适用于表

标签： postgresql composite-types

【解决方案1】：

显然修复是执行逻辑现在必须在foo.sql之前执行bar.sql，但是错误非常奇怪和误导 strong> 因为人们不希望像这样删除列 foo.foo_b，但应该删除依赖类型 foo。

【讨论】：