Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 26 Feb 2026 17:29:34 -0300
Message-Id: <DGP6EUP1QGYO.GVXRL0VYPEYW@gmail.com>
Cc: <pgsql-hackers@lists.postgresql.org>, "Peter Eisentraut"
 <peter@eisentraut.org>, "Yugo Nagata" <nagata@sraoss.co.jp>
Subject: Re: Show expression of virtual columns in error messages
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
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>
 <DG7VKZO7JWBK.3JZ1PZ7EA8C8S@gmail.com>
 <2f55b9a4-332f-45c7-9b27-590637a2bb9a@gmail.com>
 <719803.1772131627@sss.pgh.pa.us>
In-Reply-To: <719803.1772131627@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/DGP6EUP1QGYO.GVXRL0VYPEYW%40gmail.com>
Precedence: bulk

On Thu Feb 26, 2026 at 3:47 PM -03, Tom Lane wrote:
> Matheus Alcantara <matheusssilv97@gmail.com> writes:
>> Attached rebased v3 due to f80bedd52b1. No additional changes compared=
=20
>> to v2.
>
> I looked at this and frankly I think it's going in the wrong
> direction.  I agree that showing "virtual" is unhelpful, but
> I don't like this approach for a couple of reasons:
>
> 1. Inserting a column expression could easily make the error
> message annoyingly long.
>
> 2. Adding this much complexity in an error code path doesn't
> seem like a good idea.  Such paths are typically not well
> tested, and if there is any bug lurking, it will result in
> an error message quite removed from the user's problem.
>
> 3. It's making virtual generated columns behave (even more)
> differently from stored generated columns.  I think the
> general plan has been to make them act as alike as possible.
>
> So what would comport better with the behavior of stored columns
> is to show the expression's value.  I agree with you that
> calculating that in the error path is a no-go, but haven't we
> computed it earlier?  Or could we do so, if there are constraints
> to be checked?

Thanks for the feedback. After investigating the code a bit, I found
that IIUC virtual column values are actually never computed and stored
separately, they're computed by expanding the expression wherever the
column is referenced.

According to my understanding, here's how it works during constraint
checking in ExecRelCheck():

1. The constraint expression (e.g., c > 10) is loaded from the catalog
2. Virtual column references are expanded via
expand_generated_columns_in_expr(), transforming it to (a + b) > 10=20
3. ExecCheck() evaluates the entire expanded expression, reading base
column values (a, b) directly from the slot and returns the if the check
was true or false.

The virtual column value (a + b) is computed as an intermediate result
during expression evaluation of a check constraint but is never stored
anywhere accessible.

So, if all of this make sense and it's correct it seems to me that we
indeed need to compute the virtual expression value on error path to
show on error message although it would not be desirable, or I'm missing
something?

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