ncm(at)zembu(dot)com (Nathan Myers) writes:
> Of course PG is different from any O-O language. I don't know if PG
> has an equivalent to the "base-class context". I suppose PG has a long
> history of merging like-named members, and that the issue is just of
> the details of how the merge happens.
Yes; AFAICT that behavior goes back to PostQUEL. It was partially
disabled (without adequate discussion I guess) in 7.0, but it's been
around for a long time.
>> 4. All relevant constraints from all the column specifications will
>> be applied. In particular, if any of the specifications includes NOT
>> NULL, the resulting column will be NOT NULL. (But the current
>> implementation does not support inheritance of UNIQUE or PRIMARY KEY
>> constraints, and I do not have time to add that now.)
> Sounds like a TODO item...
There's something about it in TODO already. There are some definitional
issues though (should uniqueness be across ALL tables of the inheritance
hierarchy, or per-table? If the former, how would we implement it?).
I believe you can find past discussions about this in the archives.
> Do all the triggers of the base tables get applied, to be run one after
Triggers aren't inherited either. Possibly they should be, but again
I think some forethought is needed...
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-04-01 00:44:30|
|Subject: Re: Re: Changing the default value of an inherited column |
|Previous:||From: Bruce Momjian||Date: 2001-04-01 00:31:38|
|Subject: Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!!