From: Tom Lane <tgl@sss.pgh.pa.us>
To: jian he <jian.universality@gmail.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: support fast default for domain with constraints
In-reply-to: <CACJufxE_+iZBR1i49k_AHigppPwLTJi6km8NOsC7FWvKdEmmXg@mail.gmail.com>
References: <CACJufxE_+iZBR1i49k_AHigppPwLTJi6km8NOsC7FWvKdEmmXg@mail.gmail.com>
Comments: In-reply-to jian he <jian.universality@gmail.com>
	message dated "Wed, 05 Mar 2025 10:56:42 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <229412.1741144420.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 04 Mar 2025 22:13:40 -0500
Message-ID: <229413.1741144420@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/229413.1741144420%40sss.pgh.pa.us>
Precedence: bulk

jian he <jian.universality@gmail.com> writes:
> Thanks to commit aaaf9449ec6be62cb0d30ed3588dc384f56274bf[1],
> ExprState.escontext (ErrorSaveContext) was added, and ExecEvalConstraint=
NotNull,
> ExecEvalConstraintCheck were changed to use errsave instead of hard erro=
r.
> Now we can use it to evaluate CoerceToDomain in a soft error way, that
> is what this patch intended to do.

This patch appears to summarily throw away a couple of
backwards-compatibility concerns that the previous round
took care to preserve:

* not throwing an error if the default would fail the domain
constraints, but the table is empty so there is no need to
instantiate the default.

* not assuming that the domain constraints are immutable.

Now it's fair to question how important the second point is
considering that we mostly treat domain constraints as immutable
elsewhere.  But I think the first point has actual practical uses
--- for example, if you want to set things up so that inserts must
specify that column explicitly.  So I don't think it's okay to
discard that behavior.

Maybe we need a regression test case demonstrating that that
behavior exists, to discourage people from breaking it ...

			regards, tom lane