Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table
Date
Msg-id 20170424131701.GB9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Apr 21, 2017 at 1:43 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >> + Once
> >> +       partitions exist, we do not support using <literal>ONLY</literal> to
> >> +       add or drop constraints on only the partitioned table.
> >>
> >> I wonder if the following sounds a bit more informative: Once partitions
> >> exist, using <literal>ONLY</literal> will result in an error, because the
> >> constraint being added or dropped must be added or dropped from the
> >> partitions too.
> >
> > My thinking here is that we may add support later on down the line for
> > using the ONLY keyword, when the constraint has already been created on
> > the partitions themselves, so I would rather just clarify that we don't
> > (yet) support that.  Your wording, at least to me, seems to imply that
> > if the constraint was added to or dropped from the partitions then the
> > ONLY keyword could be used, which isn't accurate today.
>
> Well, I think that Amit's wording has the virtue of giving a reason
> which is basically valid, whereas someone reading your text might
> conceivably be left wondering what the reason for the restriction is.

I wonder why the restriction is there, which is probably part of the
reason that I'm thinking of phrasing the documentation that way.

Beyond a matter of round to-its, is there a reason why it couldn't (or
shouldn't) be supported?  I'm not suggesting now, of course, but in a
future release.

I could certainly see someone wanting to manage the process by which a
constriant is added by adding it one at a time to the individual
partitions and then wishing to be sure that adding it to parent only
checked that the individual partitions had the constraint and then added
it to the parent (in other words, a relatively short operation,
providing the locks are able to be acquired quickly).

> Also, I think saying that it it will result in an error is a bit more
> helpful than saying that it is is not supported, since the latter
> might lead someone to believe that it could result in undefined
> behavior (i.e. arbitrarily awful misbehavior) which is not the case.
> So I like what he wrote, for whatever that's worth.

I don't mind stating that it'll result in an error, I just don't want to
imply that there's some way to get around that error if things were done
differently.

How about:

---
Once partitions exist, using <literal>ONLY</literal> will always result
in an error as adding or dropping constraints on only the partitiioned
table, when partitions exist, is not supported.
---

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] OK, so culicidae is *still* broken
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Incorrect use of ERRCODE_UNDEFINED_COLUMN in extendedstats