Re: Fix domain fast defaults on empty tables

> On Jun 7, 2026, at 04:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andrew Dunstan <andrew(at)dunslane(dot)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.
>
>> Seems reasonable. So which of Chao's solutions do you prefer? I think
>> both will meet the pg_dump issue, not sure how much we care about the
>> case where we have deleted all the rows but not truncated the table.
>
> [ 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.
>
> 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.
>
> 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.
>
> However, I doubt that a bare "RelationGetNumberOfBlocks() == 0" check
> is acceptable: we probably need to let the table access method have
> control of this. heapam could do "RelationGetNumberOfBlocks() == 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.
>
> My recommendation: we ought to revert a0b6ef29a for now and
> redesign the optimization for v20.
>
> 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.
>
> 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.
>
> 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’m 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/