Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
От | Alexander Lakhin |
---|---|
Тема | Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently |
Дата | |
Msg-id | 67cb509e-93c7-1c7b-2388-d7e00277b344@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17872: Dropping an attribute of a composite type breaks indexes over the type silently
|
Список | pgsql-bugs |
27.03.2023 21:20, Tom Lane wrote: > Alexander Lakhin <exclusion@gmail.com> writes: >> Yes, I think something like that can resolve the issue. >> But I would also note that the problem is not with indexes only, but also >> with "... partition by list(comp_type_value)", for example. > Hmm ... really? I'd just concluded that a partitioned table is okay > as long as it doesn't yet have any partitions. Even if the modified > type is a partitioning column, there's no structure yet that could > depend on the contents of the type. (If it does have partitions, > we'll fail when we get to one of those.) The following query leads to a failure on showing a partition definition: CREATE TABLE tbl(a int, b int) PARTITION BY LIST ((tbl)); CREATE TABLE tblp PARTITION OF tbl FOR VALUES IN ('(2,4)'); ALTER TABLE tbl ALTER COLUMN a TYPE char(5); \d+ tbl (The effect depends on the values specified.) It's not exactly the dependency issue but still is related to altering a composite type. Best regards, Alexander
В списке pgsql-bugs по дате отправления: