From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: docs about FKs referencing partitioned tables |
Date: | 2019-05-27 02:49:11 |
Message-ID: | 20190527024911.GG1963@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 23, 2019 at 12:02:56AM -0700, Paul A Jungwirth wrote:
> The section in the docs (5.10) just before the one I changed has
> similar warnings:
>
>> Other types of constraints (unique, primary key, and foreign key
>> constraints) are not inherited.
>
> and
>
>> A serious limitation of the inheritance feature is that indexes
>> (including unique constraints) and foreign key constraints only
>> apply to single tables, not to their inheritance children.
Yes.
> I moved the paragraph to a section describing inheritance as an
> alternative partitioning solution to declarative partitions. Since
> using inheritance to partition a table requires giving up foreign
> keys, it seems worthwhile to include that among the other caveats. (It
> wasn't necessary to include it before because declarative partitions
> had the same drawback, and it was already expressed in the paragraph I
> took out.) In my opinion mentioning this limitation would be helpful
> to people.
Well, the point I would like to outline is that section 5.11.2 about
declarative partitioning and 5.11.3 about partitioning with
inheritance treat about two separate, independent partitioning
methods. So removing the paragraph from the declarative partitioning
section mentioning foreign keys referencing partitioned tables is
fine, because that's not the case anymore...
> I was trying to make a minimal change by keeping most of the original
> wording, but I agree that different language would be more accurate.
> What do you think of something like this?:
>
> + <listitem>
> + <para>
> + While foreign keys may be defined that reference a parent
> + table, they will not see records from its child tables. Since
> + the parent table is typically empty, adding any record (with a
> + non-null foreign key) to the referencing table will raise an error.
> + </para>
> + </listitem>
... However you are adding a paragraph for something which is
completely unrelated to the issue we are trying to fix. If I were to
add something, I think that I would be more general than what you are
trying here and just mention a link to the previous paragraph about
the caveats of inheritance as they apply to single table members of an
inheritance tree and not a full set:
"Indexes and foreign key constraint apply to single tables and not
their inheritance children, hence they have some <link>caveats</> to
be aware of."
Still this is a duplicate of a sentence which is just a couple of
paragraphs back.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-05-27 04:20:58 | Re: Inconsistent error message wording for REINDEX CONCURRENTLY |
Previous Message | Michael Paquier | 2019-05-27 02:19:39 | Re: initdb recommendations |