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 CAFjFpRehhCw2H9VKo2U31EW5nH2iqB48+trgsBwM58Bkm2=yQA@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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jul 3, 2018 at 8:19 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jul 2, 2018 at 1:46 AM, Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
>> This constraint was added to the partitioned table and inherited from
>> there. If user wants to drop that constraint for some reason, this
>> error message doesn't help. The error message tells why he can't drop
>> it, but doesn't tell, directly or indirectly, the user what he should
>> do in order to drop it.
>
> That doesn't really sound like an actual problem to me.  If the error
> is that the constraint is inherited, that suggests that the solution
> is to find the place from which it got inherited and drop it there.
> And that's in fact what you have to do.  What's the problem?  I mean,
> we could add a hint, but it's possible to make yourself sound dumb by
> giving hints that are basically obvious implications from the error
> message.  Nobody wants this sort of thing:
>
> rhaas=# drop table foo;
> ERROR:  table "foo" does not exist
> HINT: Try dropping a table with a different name that does exist, or
> first create this table before trying to drop it.

Again a wrong example and wrong comparison. I think I was clear about
the problem when I wrote

--
When there was only a single way, i.e table
inheritance, to "inherit" things users could probably guess that. But
now there are multiple ways to inherit things, we have to help user a
bit more. The user might figure out that ti's a partition of a table,
so the constraint is inherited from the partitioned table. But it will
help if we give a hint about from where the constraint was inherited
like the error message itself reads like "can not drop constraint
"p_a_check" on relation "p1" inherited from "partitioned table's name"
OR a hint "you may drop constraint "p_a_check" on the partitioned
table "partitioned table's name".
--

For some reason you have chosen to remove this from the email and
commented on previous part of it.

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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Possible bug in logical replication.
Next
From: Craig Ringer
Date:
Subject: Re: Should contrib modules install .h files?