From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Manuel Reyes Bravo <manuelreyesbravo@gmail.com>
To: Andrey Rachitskiy <pl0h0yp1@gmail.com>
Cc: Jinqing Kuang <kuangjinqingcn@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: Detaching a child table makes an expression using it unrestorable
Date: Mon, 21 Sep 2026 07:48:45 +0200
Message-ID: <65d97f78f24ddcfdd3b244451ed9b72284ef8fab.camel@cybertec.at> (raw)
In-Reply-To: <CA+bCEdC167OdU3tHnRhLjGSibDMiPHODwSncCcOCxUZdWkUORA@mail.gmail.com>
References: <c638c39b-de93-46a4-b7e9-e5613952fcb3@iki.fi>
<8E44C4A2-6184-473F-B536-F73F63AEF1D0@gmail.com>
<CAB8bMiv0tjTOsREUPf3XtgpkBoXD3gaWEwnRv8N-H8jhgZ+8fQ@mail.gmail.com>
<CA+bCEdDvsVApd+AADX=5uyj6Q5C3r5aruWNzOFaYqaFqLwE_5g@mail.gmail.com>
<CA+bCEdC167OdU3tHnRhLjGSibDMiPHODwSncCcOCxUZdWkUORA@mail.gmail.com>
On Mon, 2026-09-21 at 01:39 -0300, Manuel Reyes Bravo wrote:
> Attached is v2 of the patch that refuses ALTER COLUMN TYPE when a
> stored expression holds a constant of the row type.
>
> It fixes the wording for stand-alone composite types. v1 reported
>
> ALTER TYPE t ALTER ATTRIBUTE b TYPE varchar;
> ERROR: cannot alter table "t" because rule _RETURN on view v
> stores a constant of its row type
>
> where the existing column checks in find_composite_type_dependencies()
> correctly say "cannot alter type". Both of the new reporting sites now
> go through one helper that follows those checks (type, foreign table or
> table), and the index case names the object the same way as the others
> ("index at_tab2_idx" instead of 'an expression of "at_tab2_idx"').
> A regression test for the composite type case is added; it fails with
> v1. make check passes.
>
> I found it while reviewing Nikhil's patch in "Dropping a composite
> attribute causes data integrity violations" [1], which makes ALTER TYPE
> ... DROP ATTRIBUTE and ALTER TABLE ... DROP COLUMN call
> find_composite_type_dependencies() as well. The two patches compose:
> with both, a drop is also refused when a stored constant of the row
> type would change its meaning. The details are in that thread.
>
> [1] https://postgr.es/m/CA+UBoq0F2ua2fQEAU3-6w0oxOgFc9BgEN4gRcchiUUZ+WouVrQ@mail.gmail.com
Thanks.
I briefly looked at the patch, and I wondered if you omitted
pg_partitioned_table.partexprs on purpose.
But taking a step back, I wonder if all that is worth the effort.
PostgreSQL expects data types to be immutable, so if you modify a
composite type that is used anywhere in a persistent fashion, things
will break all over the place. I doubt that we can ever plug all the
holes.
I think it is a bad idea to use composite types in table definitions
or anything else that is persistent, but we can hardly go back on
that. Perhaps we should just forbid ALTER TYPE ... ADD/DROP/ALTER?
That would be an incompatibility, but it wouldn't break upgrade.
Yours,
Laurenz Albe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: laurenz.albe@cybertec.at, manuelreyesbravo@gmail.com, pl0h0yp1@gmail.com, kuangjinqingcn@gmail.com, hlinnaka@iki.fi, pgsql-bugs@lists.postgresql.org
Subject: Re: Detaching a child table makes an expression using it unrestorable
In-Reply-To: <65d97f78f24ddcfdd3b244451ed9b72284ef8fab.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox