On 2024-Oct-09, jian he wrote:
> CreateConstraintEntry(const char *constraintName,
> we can change
> int conInhCount,
> to
> int16 conInhCount.
> doing that, meaning we also need to refactor some of the caller functions.
Good thought, thanks.
> we can also change
> node Constraint field inhcoun
On 2024-Oct-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > ... This is because ColumnDef->inhcount is a 32-bit int, but
> > Form_pg_attribute->attinhcount is int16, so we didn't break the overflow
> > test for ColumnDef inhcount, but attinhcount has overflowed during
> > assignment.
>
> Ugh ..
Oid
CreateConstraintEntry(const char *constraintName,
Oid constraintNamespace,
char constraintType,
int conInhCount,
bool conNoInherit,
bool conPeriod,
Hi,
On 2024-10-08 18:11:39 +0200, Alvaro Herrera wrote:
> Oh and actually, we could change all these variables to be unsigned,
> since there's no use for negative inhcounts. The patch doesn't do that;
> it'd require changing the subtraction paths to use overflow-protected
> ops as well.
Unfortun
Alvaro Herrera writes:
> ... This is because ColumnDef->inhcount is a 32-bit int, but
> Form_pg_attribute->attinhcount is int16, so we didn't break the overflow
> test for ColumnDef inhcount, but attinhcount has overflowed during
> assignment.
Ugh ... somebody's ancient oversight there. Or maybe
Per a review comment on the not-null constraint patch from Jian He, I
played a bit with the various inhcount variables in the tree, with this
simple test which creates a child table and 2^16+1 parents:
for i in `seq 1 $((2 ** 16+1))`; do echo "create table parent_$i (a int);";
done | psql
(echo
