Search Postgresql Archives

Re: [HACKERS] Inherited constraints and search paths (was Re:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Simon Riggs <simon@xxxxxxxxxxxxxxx> 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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux