Re: Remove mention in docs that foreign keys on partitioned tablesare not supported - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Date
Msg-id 3a643aa0-ca2a-44d1-3b13-9227f5cf523b@lab.ntt.co.jp
Whole thread Raw
In response to Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
List pgsql-hackers
On 2018/06/06 20:51, Ashutosh Bapat wrote:
> The existing wording suggests that the user
> creates the triggers on the partitioned table, and that will be
> supported always, which can lead to problems.

Do you mean the following wording

"BEFORE ROW triggers, if necessary, must be defined on individual
partitions, not the partitioned table."

suggests that user *can* create triggers on the partitioned table?  I
guess I can see how one may read it that way.  How about we make it say
something like:

"BEFORE ROW triggers are not supported on partitioned tables; a user can
still define them, if necessary, on individual partitions though."

> With this description,
> if the user finds out that BEFORE triggers are supported on partitions
> and creates those, and we implement something to support those on
> partitioned table, s/he will have to change the implementation
> accordingly.

So you mean that the existing wording *encourages* users to use the
feature to create BR triggers on individual partitions whereas it
shouldn't, that is, users can find out about that feature by themselves by
trying it out?  I think the revised wording I proposed above isn't too
encouraging.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_replication_slot_advance to return NULL instead of 0/0 ifslot not advanced
Next
From: Craig Ringer
Date:
Subject: Re: libpq compression