public inbox for [email protected]
help / color / mirror / Atom feedFrom: Viktor Holmberg <[email protected]>
To: Andrew Dunstan <[email protected]>
To: jian he <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: support fast default for domain with constraints
Date: Thu, 12 Mar 2026 11:15:56 +0100
Message-ID: <86e2c66e-f07b-4285-b42e-e3d821e0f0d7@Spark> (raw)
In-Reply-To: <CACJufxHomghtudwKpxqbVyy2n+cBPrahJjnpAo2OvRRXN-UE4w@mail.gmail.com>
References: <CACJufxE_+iZBR1i49k_AHigppPwLTJi6km8NOsC7FWvKdEmmXg@mail.gmail.com>
<[email protected]>
<CACJufxGZqTUqOCmwVveq4TGG6UXrMnODkMw7x5LV4DM4RkNRcw@mail.gmail.com>
<CACJufxHtbn6pUPt8RRXv8BAFX67K5gyqR5SGwu8P1nSEF=ts9g@mail.gmail.com>
<CACJufxECb4nVjssRPknepNmqF2CR0ycPzTmJZPxoWYK4JD-mFQ@mail.gmail.com>
<CACJufxGs_A0mrq9StOFAkVnK9x1U_s0+KuybGKUt2VmspC90Hw@mail.gmail.com>
<CACJufxGNCw51aeVxXOtgzgbE9J710e91umNzH-56rG5tmtK8mw@mail.gmail.com>
<CACJufxFdzChzGn659CabeYSJA2fN_NNuZLShqKN5grbxLLK5LA@mail.gmail.com>
<CACJufxGFP5VJJwPqTZJ_fQq_BKLqD_90JQ49AJH6fPqSmdFSnQ@mail.gmail.com>
<CACJufxG-NQmEutUnsA3q1RV1iT5MWpaj3MSOH4aVo_UNZUA86g@mail.gmail.com>
<[email protected]>
<CACJufxE=VV5xvRLUhVP2Oej3SpZs1+Ksr=QUACm4ZUhE9TjSng@mail.gmail.com>
<5a8c55ea-81d3-47f4-aff9-a89fabcc2304@Spark>
<[email protected]>
<CACJufxHomghtudwKpxqbVyy2n+cBPrahJjnpAo2OvRRXN-UE4w@mail.gmail.com>
On 12 Mar 2026 at 04:36 +0100, jian he <[email protected]>, wrote:
> On Thu, Mar 12, 2026 at 3:50 AM Andrew Dunstan <[email protected]> wrote:
> > Also added some tests.
>
> V11 looks good to me.
>
>
> On Wed, Mar 11, 2026 at 6:34 PM Viktor Holmberg <[email protected]> wrote:
> >
> > I’ve been burned my this issue in the past so would be great if this could get in.
> >
> > + /*
> > + * If the domain has volatile constraints, we must do a table rewrite
> > + * since the constraint result could differ per row and cannot be
> > + * evaluated once and cached as a missing value.
> > + */
> > + if (has_volatile)
> > + {
> > + Assert(has_domain_constraints);
> > + tab->rewrite |= AT_REWRITE_DEFAULT_VAL;
> > + }
> >
> > I'm not sure. But seems to me this makes the pre-existing guard for virtual columns
> > redundant?
> > I mean this code on line 7633:
> > if (colDef->generated != ATTRIBUTE_GENERATED_VIRTUAL)
> > tab->rewrite |= AT_REWRITE_DEFAULT_VAL;
> >
>
> If the first `if (has_volatile)` is false, then
> > if (colDef->generated != ATTRIBUTE_GENERATED_VIRTUAL)
> > tab->rewrite |= AT_REWRITE_DEFAULT_VAL;
> is still reachable.
>
> > Also, perhaps virtual generated columns could use a test?
>
> Virtual generated columns based on domain are not currently supported.
> I have a patch for it: https://commitfest.postgresql.org/patch/5725
> but it's not doable now because of
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=0cd69b3d7ef357f2b43258de5831c4de0bd51dec
> You may also be interested in https://commitfest.postgresql.org/patch/5907
>
> --
> jian
> https://www.enterprisedb.com/
Nice, v11 looks good to me. I’ll change the status of the commitfest entry to ready for committer.
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: support fast default for domain with constraints
In-Reply-To: <86e2c66e-f07b-4285-b42e-e3d821e0f0d7@Spark>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox