> I think we can fix this by throwing an error only if this constraint > was added directly to the table and not through > inheritance/propagation from the parent, we can do this using the > "is_local" flag, i have checked and all tests passed.
Hmm, I'm not opposed to this; does it change any other behavior? I think it's important to see whether there are other corner cases that would react to this behavior change. For example, what would happen if two existing parents have a not-null constraint on the same column? Is there a change for combined LIKE and regular inheritance? I think we should have reasonable reactions to each of those scenarios:
create table parent (a int not null); create table parent2 (a int not null);
create table child4 (like parent) inherits (parent2); -- and so on as your imagination allows
as you have suggested i have looked whether it effects the other behaviour ,during table creation with not null constraints i observed that flow doesn't touch the AdjustNotNullInheritance where we added the error message, When running CREATE TABLE, the standard NOT NULL merging logic is handled by DefineRelation -> AddRelationNotNullConstraints. This function explicitly handles the "Constraint Selection" logic (prioritizing the Child's constraint if present, otherwise defaulting to the 1st parent's constraint), please correct me if I totally understood your concerns wrong here.
Would you be able to send a patch based on this idea and what I sent earlier?
