Note: You can propose changes using the forum below.
The goal of this project is to have the documented table inheritance caveats fixed and released.
As of version 9.1, three caveats are documented as follows. "Cities" is the parent (inherited) table and "capitals" is the child (inheriting) table:
> If we declared cities.name to be UNIQUE or a PRIMARY KEY, this would not stop the capitals table from having rows with names duplicating rows in cities. And those duplicate rows would by default show up in queries from cities. In fact, by default capitals would have no unique constraint at all, and so could contain multiple rows with the same name. You could add a unique constraint to capitals, but this would not prevent duplication compared to cities.
> Similarly, if we were to specify that cities.name REFERENCES some other table, this constraint would not automatically propagate to capitals. In this case you could work around it by manually adding the same REFERENCES constraint to capitals.
> Specifying that another table's column REFERENCES cities(name) would allow the other table to contain city names, but not capital names. There is no good workaround for this case.
a. To consider the project completed, the fix or fixes must be present in a PostgreSQL release as part of the core (as opposed to being part of contrib). -- This is to make sure it got through the PostgreSQL review process.
b. If other caveats are found to be documented in the manual before the fixed version (in whatever section that corresponds to the current 5.8.1 section), those must be fixed too. For example, if version 9.2 is not the fixed version but its manual documents a fourth caveat, it must be fixed too for the project to be considered fulfilled.
c. Submitted commit messages in patches must: 1) reference this project (a code like "FIX-INHERIT" is enough), 2) document the intention of the code (what the new code is supposed to do) and 3) if removing code, why was it wrong. -- This is to make the commits easily searchable.
d. Enough documentation must be published (and kept public, see e.) for others to understand the fixes and support them in the future. -- This is to allow the person not to get tied by e) alone.
e. A commitment must be made to support the fixes and its documentation for the rest of the major release and one more major release.