Re: support fast default for domain with constraints - Mailing list pgsql-hackers

From Tom Lane
Subject Re: support fast default for domain with constraints
Date
Msg-id 229413.1741144420@sss.pgh.pa.us
Whole thread Raw
In response to support fast default for domain with constraints  (jian he <jian.universality@gmail.com>)
Responses Re: support fast default for domain with constraints
List pgsql-hackers
jian he <jian.universality@gmail.com> writes:
> Thanks to commit aaaf9449ec6be62cb0d30ed3588dc384f56274bf[1],
> ExprState.escontext (ErrorSaveContext) was added, and ExecEvalConstraintNotNull,
> ExecEvalConstraintCheck were changed to use errsave instead of hard error.
> 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



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: support fast default for domain with constraints
Next
From: Michael Paquier
Date:
Subject: Monitoring gaps in XLogWalRcvWrite() for the WAL receiver