Subject: Re: Show expression of virtual columns in error messages

From: "Matheus Alcantara" <[email-masked]>
Date: Wed, 04 Feb 2026 14:54:11 -0300

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).

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

---

From: Yugo Nagata <[email-masked]>
Date: Thu, 5 Feb 2026 11:45:21 +0900

On Wed, 04 Feb 2026 14:54:11 -0300

>     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 <[email-masked]>