Simon Riggs <simon@2ndquadrant.com> writes:
> If you were going to fix that by adding a column that allows me to tell
> the difference between inherited and non-inherited relations, that would
> be a very useful piece of info for partition elimination.
Inherited and non-inherited constraints you mean? Probably. I hadn't
thought through the details, but certainly there would need to be some
better way of telling whether a constraint was inherited.
> If you're looking for other inheritance wierdies, you may also be
> interested in this one. When you create a table that inherits from a
> master, it copies across constraints with exactly matching names. If a
> constraint is then added to the master, the constraint is copied across
> to the child but does not have the same name.
Hmm, that's weird: if you give an explicit name ("add constraint foo")
then it's used, but if you let the system generate the name it's not
the same. I agree that was probably unintentional. Does anyone want to
argue for keeping it this way?
regression=# create table parent(f1 int check (f1 > 0));
CREATE TABLE
regression=# create table child() inherits(parent);
CREATE TABLE
regression=# alter table parent add check (f1 > 100);
ALTER TABLE
regression=# \d parent
Table "public.parent"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer |
Check constraints:
"parent_f1_check" CHECK (f1 > 0)
"parent_f1_check1" CHECK (f1 > 100)
regression=# \d child
Table "public.child"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer |
Check constraints:
"parent_f1_check" CHECK (f1 > 0)
"child_f1_check" CHECK (f1 > 100)
Inherits: parent
(This is, btw, another case that would break the current code for
identifying inherited constraints in pg_dump. Given a positive marker
for an inherited constraint, however, we wouldn't care. So I don't
think we need to consider pg_dump in debating which behavior we like.)
regards, tom lane
