On Tue, Oct 13, 2026 at 9:43 PM Álvaro Herrera <[email protected]> wrote: > I find this very surprising. Are we sure that it makes sense for a > partition to have a generating expression that differs from the one in > the parent table?
No, I don't think it makes sense for a partition to have a different virtual generation expression than its parent. I raised this exact same complaint in [1], the paragraph starting with "Regarding #4", quoted below: Regarding #4, the fix is to not trust NOT NULL on a virtual generated column of a partitioned table. But I don't like this fix at all. I think the real problem is that a partition is allowed to have a different virtual generation expression than its parent. The constraint is enforced with the partition's expression, while a query on the parent computes the column with the parent's expression. So even on v18, a NOT NULL column can read as NULL through the parent, and the same goes for CHECK constraints. That seems fragile to me, and I suspect it will bite us again. CC'ing Peter here. I'm not sure why virtual generated columns are designed this way, or if this is required by the SQL standard. But I can see it breaks a lot of things, and what this commit does is just to work-around one of the things that design breaks. [1] https://postgr.es/m/cambws4-dfvuxsu1fwftd8hzypkssn1uyjepfmdb6bqb58pa...@mail.gmail.com - Richard
