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

From Ashutosh Bapat
Subject Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Date
Msg-id CAFjFpRfEYqw2nP79UBVN42+udP=ORoHe2emOid5XNXzJwrjU5w@mail.gmail.com
Whole thread Raw
In response to Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
List pgsql-hackers
On Thu, Jun 14, 2018 at 6:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 7:51 AM, Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
>> On Tue, Jun 5, 2018 at 10:38 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>
>>>  - BEFORE row triggers are not supported
>>
>> I think this is fine. 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. 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.
>
> It sounds like you want to try to hide from users the fact that they
> can create triggers on the individual partitions.

No. I never said that in my mails (see [1], [2]) I object to the
explicit suggestion that they can/should create BEFORE ROW triggers on
partitions since those are not supported on the partitioned table.

>  I think that's the
> wrong approach.  First of all, it's not going to work, because people
> are going to find out about it and do it anyway.  Secondly, the
> documentation's job is to tell you about the system's capabilities,
> not conceal them from you.

Neither is documentation's job to "suggest" something that can lead to
problems in future.

[1] https://www.postgresql.org/message-id/CAFjFpRfzCVnuL0L3_qAFqr5xFN-EynbMoW4gf-2moO7gNazADA@mail.gmail.com
[2] https://www.postgresql.org/message-id/CAFjFpRfzCVnuL0L3_qAFqr5xFN-EynbMoW4gf-2moO7gNazADA%40mail.gmail.com

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: WAL prefetch
Next
From: Robert Haas
Date:
Subject: Re: Fix some error handling for read() and errno