On Wed, 04 Feb 2026 14:54:11 -0300
"Matheus Alcantara" <matheusssilv97@gmail.com> wrote:
> On Wed Feb 4, 2026 at 11:57 AM -03, Peter Eisentraut wrote:
> > On 03.02.26 15:06, Matheus Alcantara wrote:
> >> The attached patch changes this behavior to show the virtual column
> >> expression instead:
> >>
> >> ERROR: new row for relation "t" violates check constraint "t_c_check"
> >> DETAIL: Failing row contains (5, 10, a * 2).
> >
> > Could be useful, but in this context you don't know which column is "a"?
>
> I agree but we at least show more information to the user. The user may
> still need to check the table definition to understand the constraint or
> to get the column ordering of the table to understand what the value of
> "a" is being used to compute the expression.
>
> If the statement declare the columns that the values are referecing this
> could be easier to know (e.g INSERT INTO t(a, b) VALUES (5, 10)) but the
> user may still need to check the table definition to understand the
> constraint.
>
> I see this patch as a way to at least give more information to user
> about the error.
>
> Another possibility would be to get the actual values of "a" for example
> and show it on the error message, e.g:
>
> ERROR: new row for relation "t" violates check constraint "t_c_check"
> DETAIL: Failing row contains (5, 10, 5 * 2).
That would indeed be more useful. One way to achieve this might be to
modify deparse_context and get_variable() so that a Var is displayed as its
actual value.
Another possibility would be to include column names in the DETAIL message,
for example:
ERROR: new row for relation "t" violates check constraint "t_c_check"
DETAIL: Failing row contains (a, b, c)=(5, 10, a * 2).
Although this would change the existing message format, including column
names could generally provide users with more information about the error.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
