On Fri, 25 Sept 2026 at 11:05, Michael Paquier <[email protected]> wrote: > > On Fri, Sep 25, 2026 at 08:41:38AM +0000, Bertrand Drouvot wrote: > > Just a few comments: > > > > === 1 > > > > It needs a rebase due to 926627bf902
Done
> > === 2
> >
> > + ereport(ERROR,
> > + errmsg("too many check constraints on relation
> > \"%s\"",
> > + RelationGetQualifiedRelationName(rel)));
> >
> >
> > I think ERRCODE_PROGRAM_LIMIT_EXCEEDED would be appropriate here?
Done.
> > numchecks++;
> > +
> > + if (numchecks >= PG_INT16_MAX)
> > + ereport(ERROR,
> > + errmsg("too many check constraints on relation
> > \"%s\"",
> > + RelationGetQualifiedRelationName(rel)));
> >
> > I wonder if it wouldn't make more sense to check numchecks >= PG_INT16_MAX
> > before
> > calling StoreRelCheck()? That would avoid inserting the constraint,
> > recording its
> > dependencies and invoking the post create hook for an object that will be
> > rejected.
>
> Yeah, let's do that. That's unlikely but it would just be a waste and
> that's just switching the order of things.
Also done. Thanks for the fast replies.
Attached v3:
* Add errcode(PROGRAM_LIMIT_EXCEEDED) to the ereports.
* Use pg_add_s16_overflow() to detect the overflows.
This includes changing the type of local numchecks variables to
int16. SetRelationNumChecks's signature is unchanged.
* Move the overflow checks to before StoreRelCheck.
This saves one dirty tuple in catalog tables when that overflow happens.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
v3-0001-Enforce-the-pg_class.relchecks-limit.patch
Description: Binary data
