Re: not null constraints, again

On 2024-Sep-02, Tender Wang wrote:

> The attached patch adds List *nnconstraints, which store the not-null
> definition, in struct CreateStmt. This makes me a little confused
> about List *constraints in struct CreateStmt. Actually, the List
> constraints store ckeck constraint, and it will be better if the
> comments can reflect that. Re-naming it to List *ckconstraints seems
> more reasonable. But a lot of codes that use stmt->constraints will be
> changed.

Well, if you look at the comment about CreateStmt, there's this:

/* ----------------------
* Create Table Statement
*
* NOTE: in the raw gram.y output, ColumnDef and Constraint nodes are
* intermixed in tableElts, and constraints and nnconstraints are NIL. After
* parse analysis, tableElts contains just ColumnDefs, nnconstraints contains
* Constraint nodes of CONSTR_NOTNULL type from various sources, and
* constraints contains just CONSTR_CHECK Constraint nodes.
* ----------------------
*/

So if we were to rename 'constraints' to 'ckconstraints', it would no
longer reflect the fact that not-null ones can be in the former list
initially.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)