On 05/10/16 03:50, Robert Haas wrote:
> On Tue, Oct 4, 2016 at 4:02 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> [ latest patch set ]
>
> Reviewing 0003:
>
> + with matching types and no more. Also, it must have all the matching
> + constraints as the target table. That includes both <literal>NOT NULL</>
> + and <literal>CHECK</> constraints. If some <literal>CHECK</literal>
> + constraint of the table being attached is marked <literal>NO
> INHERIT</literal>,
> + the command will fail; such constraints must either be dropped or
> + recreated without the <literal>NO INHERIT</literal> mark.
>
> Why all of these requirements? We could instead perform a scan to
> validate that the constraints are met. I think the way this should
> work is:
I think it's survivable limitation in initial version, it does not seem
to me like there is anything that prevents improving this in some follow
up patch.
>
> + Currently <literal>UNIQUE</literal>, <literal>PRIMARY KEY</literal>, and
> + <literal>FOREIGN KEY</literal> constraints are not considered, but that
> + might change in the future.
>
> Really? Changing that sounds impractical to me.
>
Which part of that statement?
>
> + Note that if a partition being detached is itself a partitioned table,
> + it continues to exist as such.
>
> You don't really need to say this, I think. All of the properties of
> the detached table are retained, not only its partitioning status.
> You wouldn't like it if I told you to document "note that if a
> partition being detached is unlogged, it will still be unlogged".
>
I think this is bit different though, it basically means you are
detaching whole branch from the rest of the partitioning tree, not just
that one partition. To me that's worth mentioning to avoid potential
confusion.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services