Re: Adding a stored generated column without long-lived locks - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Adding a stored generated column without long-lived locks
Date
Msg-id e569761f7ba04e3dd2ae947e4ceca5b440009161.camel@cybertec.at
Whole thread
In response to Re: Adding a stored generated column without long-lived locks  ("Alberto Piai" <alberto.piai@gmail.com>)
Responses Re: Adding a stored generated column without long-lived locks
List pgsql-hackers
On Fri, 2026-10-02 at 01:30 +0200, Alberto Piai wrote:
> On Thu Sep 24, 2026 at 12:47 PM CEST, Laurenz Albe wrote:
> > On Thu, 2026-09-24 at 00:19 +0200, Alberto Piai wrote:
> > > I find Matthias' proposal of exposing a function to check image equality
> > > very compelling for the purpose of this patch: besides fixing this
> > > problem, it would also make the command usable for data types which
> > > don't define = (json), as well as those which don't (can't?) define
> > > equalimage()... jsonb, numeric but also tsvector and PostGIS geometry.
> >
> > True, "tsvector" is limiting; I can see people wanting that for
> > generated columns.
>
> I spent some time thinking about the situation [...]
>
> The notion of image equality already is somewhat exposed to the user
> through *= (record_image_eq). I wonder what could be the downsides of
> also exposing it for a single Datum.

You could simply require the constraint to be

 ROW(col)::record *= ROW(expression)::record

That would also behave as desired for NULL values.
True, it looks hacky, but as you said, it is a constraint created
for this special purpose.

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Alexander Kukushkin
Date:
Subject: Re: pg_dump: assert failure sorting casts/transforms
Next
From: Shinya Kato
Date:
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples