Re: MERGE/SPLIT PARTITIONS issues/questions

> As a result, if the table contains generated
> columns, the data in the newly created partition may not be identical to the
> combined contents of the merged partitions.
>
> Therefore, when the partitioned table contains generated columns, we must
> reverify NOT NULL constraints, CHECK constraints, and foreign key constraints
> for ALTER TABLE ... MERGE PARTITION.

Yes, we can certainly can patch it this way. But should we? This
current behavior is inconsistent with how generated columns behave
with other SQL commands. That's why I didn't attach a patch in my
previous emails, I think the current way this behaves is wrong.

My proposal would be to reject MERGE if it would cause a difference in
generator expressions (or if it causes any other surprising changes),
and keep the exact definition of the partition for SPLIT. Otherwise we
end up with a surprising behavior in PG19, and if we want to fix it in
later releases, it'll be a significant behavior change between major
versions for the same command.