From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Improve handling of inherited GENERATED expressions. |
Date: | 2023-01-12 10:52:00 |
Message-ID: | ff51607f-f3d7-688f-90be-4f3d16cefd40@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 2023-01-11 We 15:55, Tom Lane wrote:
> Improve handling of inherited GENERATED expressions.
>
> In both partitioning and traditional inheritance, require child
> columns to be GENERATED if and only if their parent(s) are.
> Formerly we allowed the case of an inherited column being
> GENERATED when its parent isn't, but that results in inconsistent
> behavior: the column can be directly updated through an UPDATE
> on the parent table, leading to it containing a user-supplied
> value that might not match the generation expression. This also
> fixes an oversight that we enforced partition-key-columns-can't-
> be-GENERATED against parent tables, but not against child tables
> that were dynamically attached to them.
>
> Also, remove the restriction that the child's generation expression
> be equivalent to the parent's. In the wake of commit 3f7836ff6,
> there doesn't seem to be any reason that we need that restriction,
> since generation expressions are always computed per-table anyway.
> By removing this, we can also allow a child to merge multiple
> inheritance parents with inconsistent generation expressions, by
> overriding them with its own expression, much as we've long allowed
> for DEFAULT expressions.
>
> Since we're rejecting a case that we used to accept, this doesn't
> seem like a back-patchable change. Given the lack of field
> complaints about the inconsistent behavior, it's likely that no
> one is doing this anyway, but we won't change it in minor releases.
This appears to have caused a problem with cross-version upgrade. It's
not showing on the uploaded buildfarm logs (I will fix that) but the
error from crake is this:
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 424; 1259 25257 TABLE gtest_normal_child buildfarm
pg_restore: error: could not execute query: ERROR: column "b" in child table must not be a generated column
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('25259'::pg_catalog.oid);
-- For binary upgrade, must preserve pg_type array oid
SELECT pg_catalog.binary_upgrade_set_next_array_pg_type_oid('25258'::pg_catalog.oid);
-- For binary upgrade, must preserve pg_class oids and relfilenodes
SELECT pg_catalog.binary_upgrade_set_next_heap_pg_class_oid('25257'::pg_catalog.oid);
SELECT pg_catalog.binary_upgrade_set_next_heap_relfilenode('25257'::pg_catalog.oid);
CREATE TABLE "public"."gtest_normal_child" (
"a" integer,
"b" integer GENERATED ALWAYS AS (("a" * 2)) STORED
);
-- For binary upgrade, set up inheritance this way.
ALTER TABLE ONLY "public"."gtest_normal_child" INHERIT "public"."gtest_normal";
-- For binary upgrade, set heap's relfrozenxid and relminmxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '6388', relminmxid = '1'
WHERE oid = '"public"."gtest_normal_child"'::pg_catalog.regclass;
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-01-12 11:17:46 | Re: pgsql: Sample postgres_fdw tables remotely during ANALYZE |
Previous Message | Peter Eisentraut | 2023-01-12 07:14:51 | pgsql: Constify the arguments of ilist.c/h functions |