| From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
|---|---|
| To: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
| Cc: | "Peter Eisentraut" <peter(at)eisentraut(dot)org>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Show expression of virtual columns in error messages |
| Date: | 2026-02-06 03:54:14 |
| Message-ID: | 20260206125414.8f8c5f5735aa34fb05c5cc72@sraoss.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 05 Feb 2026 15:51:54 -0300
"Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> 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 <nagata(at)sraoss(dot)co(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-02-06 04:32:36 | Re: Make wal_receiver_timeout configurable per subscription |
| Previous Message | jian he | 2026-02-06 03:40:02 | Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row |