Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 06 Feb 2026 09:25:04 -0300
Message-Id: <DG7VKZO7JWBK.3JZ1PZ7EA8C8S@gmail.com>
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Yugo Nagata" <nagata@sraoss.co.jp>
Cc: "Peter Eisentraut" <peter@eisentraut.org>,
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: Show expression of virtual columns in error messages
References: <DG5DV8SED62G.2WFJB46D7WIT8@gmail.com>
 <7c18e854-0ddb-4670-b0c4-f2541b5edd91@eisentraut.org>
 <DG6DBW8NDTJC.1U9ELI7JCWOEB@gmail.com>
 <20260205114521.6fed028d8d3185663f3c4226@sraoss.co.jp>
 <DG796MZZAE5S.224STEF6SZTBZ@gmail.com>
 <20260206125414.8f8c5f5735aa34fb05c5cc72@sraoss.co.jp>
In-Reply-To: <20260206125414.8f8c5f5735aa34fb05c5cc72@sraoss.co.jp>
Archived-At: <https://www.postgresql.org/message-id/DG7VKZO7JWBK.3JZ1PZ7EA8C8S%40gmail.com>
Precedence: bulk

On Fri Feb 6, 2026 at 12:54 AM -03, Yugo Nagata wrote:
>> >> Another possibility would be to get the actual values of "a" for exam=
ple
>> >> and show it on the error message, e.g:
>> >>=20
>> >>     ERROR:  new row for relation "t" violates check constraint "t_c_c=
heck"
>> >>     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 a=
s its
>> > actual value.
>> >
>> I'm not sure if I understand how modifying deparse_context_for() could
>> help on this.
>>=20
>> 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.
>
Yeah, after parsing we don't have the original string representation of
the parse node, so at deparse_expression() it has it's own style to
deparse nodes. I don't think that it's an issue and I also think that
it's accepttable.=20

> Overall, this patch looks good to me.
>
Thank you for reviewing the patch!

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