On Thu, 05 Feb 2026 15:51:54 -0300 "Matheus Alcantara" <[email protected]> wrote:
> On Wed Feb 4, 2026 at 11:45 PM -03, Yugo Nagata wrote: > >> 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. > > > I'm not sure if I understand how modifying deparse_context_for() could > help on this. > > What I did was to use the expression_tree_mutator API to mutate the > virtual column expression to replace any Var reference with the value > into the TupleTableSlot. Please see the attached v2 version. I initially thought about having deparse_context_for() directly output actual values for Var references, but that does not seem like a good approach. Replacing Vars with Consts beforehand using expression_tree_mutator, as you did, looks like a better solution. One thing I noticed is that some expressions in virtual columns (e.g., NULL and negative integers) differ from those in normal columns, for example in the following (null vs. NULL): +DETAIL: Failing row contains (null, NULLIF(NULL::integer, 0)). However, this seems acceptable. Overall, this patch looks good to me. Regards, Yugo Nagata > > 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. > > > I think that this could make the error output too verbose when there is > a lot of columns involved on the statement. > > -- > Matheus Alcantara > EDB: https://www.enterprisedb.com > -- Yugo Nagata <[email protected]>
