| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Alberto Piai <alberto(dot)piai(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Adding a stored generated column without long-lived locks |
| Date: | 2026-10-03 01:25:49 |
| Message-ID: | 27824d022b9ddf7edcaa11f450a6cb29b4f3fe7a.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2026-10-02 at 18:58 +0200, Matthias van de Meent wrote:
> On Fri, 2 Oct 2026 at 09:30, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> >
> > 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.
>
> I don't think that's a good solution: Whilst it may work, it also
> adds significant and potentially unnecessary overhead to the execution
> of the CHECK constraint. The added complexity in the expression
> itself also increases the chance of a user defining the constraint
> incorrectly.
All of that is correct, but the constraint is not permanent, so you don't
have to pay the slight overhead for the more complicated expression
permanently. If the user defines the constraint wrongly, nothing bad
can happen: ALTER TABLE will complain that there is no appropriate
constraint. Probably annoying, but no damage done.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-03 01:48:37 | Re: Fix reindexdb with parallel index-level conrurrent run |
| Previous Message | Michael Paquier | 2026-10-02 23:48:00 | Re: injection_points: canceled or terminated waiters leak their wait slots |