Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Fix domain fast defaults on empty tables
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <36611.1780777185@sss.pgh.pa.us>
Date: Sun, 7 Jun 2026 10:09:44 +0800
Cc: Andrew Dunstan <andrew@dunslane.net>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
 pgsql-hackers@lists.postgresql.org,
 jian he <jian.universality@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <801E695B-F659-4D21-95E8-02F9EE505AF8@gmail.com>
References: <7033D663-DDB4-4B35-922C-F33DE53B1502@gmail.com>
 <219843CF-9B49-404A-838D-88D51902B978@iki.fi>
 <3590551.1780668509@sss.pgh.pa.us>
 <203a49c2-52e4-49ab-b644-ef6044266145@dunslane.net>
 <36611.1780777185@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/801E695B-F659-4D21-95E8-02F9EE505AF8%40gmail.com>
Precedence: bulk


> On Jun 7, 2026, at 04:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 2026-06-05 Fr 10:08 AM, Tom Lane wrote:
>>> Concretely, I'm pretty sure it is a hazard for pg_dump, which thinks
>>> it can freely transform bits of CREATE operations into ALTERs.
>>> I didn't try to make an example case, but I suspect it is now =
possible
>>> to create a database that will fail dump/restore because of this
>>> inconsistency.
>=20
>> Seems reasonable. So which of Chao's solutions do you prefer? I think=20=

>> both will meet the pg_dump issue, not sure how much we care about the=20=

>> case where we have deleted all the rows but not truncated the table.
>=20
> [ studies it a bit ...]  TBH, I don't like either of these,
> nor do I like a0b6ef29a to begin with.  The fundamental problem
> with this whole mess is that it treats certain kinds of
> default-expression evaluation error (i.e., domain CHECK failures)
> differently from others.  There is no way that that leads to a
> consistent user experience.  The current complaint is one
> manifestation of that, but I'm sure there are others, eg having
> to do with domain coercions lower down in a default expression.
>=20
> It could work if ExecPrepareExprWithContext were capable of
> soft-trapping essentially all execution errors, but that's
> not true today and I strongly doubt it ever will be true.
>=20
> I think Chao's v1-s2-0001 points the way towards what could be a
> workable solution: if we see that the table is known empty (after
> we already have exclusive lock on it!), we could skip both the table
> rewrite and the insertion of an attmissingval, and thereby not need
> to evaluate the default at all during ALTER TABLE.  As Chao says,
> simplistic versions of "known empty" would expose some user-visible
> behavioral inconsistencies, but I'm not sure how much that matters.
> For pg_dump and similar applications we would get the behavior we
> needed even with just an is-physically-empty check, since all their
> CREATE/ALTER DDL happens before we ever insert any data.  You could
> imagine going further and scanning the table for live tuples, but
> I don't know that that's going to be worth the cycles.
>=20
> However, I doubt that a bare "RelationGetNumberOfBlocks() =3D=3D 0" =
check
> is acceptable: we probably need to let the table access method have
> control of this.  heapam could do "RelationGetNumberOfBlocks() =3D=3D =
0",
> but other TAMs might need to do something else.  So that means that
> this path requires a new TableAmRoutine method, and that probably
> puts it in the too-late-for-v19 category.
>=20
> My recommendation: we ought to revert a0b6ef29a for now and
> redesign the optimization for v20.
>=20
> If you don't like that answer, I'd be firmly against v1-s1-0001
> in any case.  It repeats the classic mistake of supposing that
> we can PG_CATCH random errors and not invoke transaction cleanup.
>=20
> BTW, I do not like the fact that a0b6ef29a removed the comment
> stanza explaining why we need this fake default expression at all.
> That's still largely applicable AFAICS.
>=20
> regards, tom lane

Thanks, Tom, for the detailed explanation.

I'll hold off here and wait for Andrew's decision on how to proceed. =
Sounds like reverting a0b6ef29a may be the preferred option for now.

For v1-s2, I=E2=80=99m not ware of a better way to decide whether a =
table is known empty. I ever considered a count(*)-style scan or a LIMIT =
1 scan, but those seem worse, they would add a new table scan inside =
ALTER TABLE just to decide whether to evaluate the default.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/