Hello,
On 2026-Jan-26, Srinath Reddy Sadipiralla wrote:
> i looked into this,
Thank you!
> the reason for these failures was when the given name for a constraint
> for a parent table propagates to the child table because of
> inheritance the name conflicts and throws "mismatching constraint
> name" error we added,
Right, that's what I saw.
> 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 child1 () inherits (parent, parent2);
create table child2 () inherits (parent2, parent);
create table child3 (not null a) inherits (parent2, parent);
create table child4 (like parent) inherits (parent2);
-- and so on as your imagination allows
Would you be able to send a patch based on this idea and what I sent
earlier?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Las navajas y los monos deben estar siempre distantes" (Germán Poo)
