BUG: pg_class.relchecks overflow, making table undroppable

Hi,

There's probably no user that finds good use for this many check
constraints, but users *can* create > 2^15 CHECK constraints on a
table, and doing so will overflow the int16 (sqltype int2) column in
which the relation's count of those is stored.

This causes various issues, such as possible WARNING spam to users
that need to load that relation into relcache, and an inability to
drop the relation because dropping the table requires the constraints
to be dropped first, and dropping a constraint decrements the counter
that has a check is in place to avoid the counter ever dropping below
zero (with an error if you try to decrement non-positive counter
values).

I think we should forbid creating such large amounts of CHECK
constraints (as attached, backpatch-safe), or drop the "relchecks"
field wholesale/replace it with a 'haschecks' field.

Also attached is an SQL script that shows the issue, and which doesn't
fail in the unsafe manner once PG is patched with the attached patch.

Note: the attached patch does not solve any issues in existing
databases with overflowed relchecks fields.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)