On Mon, Apr 24, 2017 at 9:17 AM, Stephen Frost <sfr...@snowman.net> wrote: > 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 don't see any particular reason, but I haven't looked into the matter deeply. One thing to consider is that you can already more or less do exactly that thing, like this: rhaas=# create table foo (a int, b text) partition by range (a); CREATE TABLE Time: 4.738 ms rhaas=# create table foo1 partition of foo for values from (0) to (100); CREATE TABLE Time: 5.162 ms rhaas=# insert into foo1 select 1, 'snarf' from generate_series(1,10000000) g; INSERT 0 10000000 Time: 12835.153 ms (00:12.835) rhaas=# alter table foo1 add constraint xyz check (b != 'nope'); ALTER TABLE Time: 1059.728 ms (00:01.060) rhaas=# alter table foo add constraint xyz check (b != 'nope'); NOTICE: merging constraint "xyz" with inherited definition ALTER TABLE Time: 1.243 ms So we may not really need another way to do it. >> 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. > --- I still prefer Amit's language, but it's not worth to me to keep arguing about it. If you prefer what you've written there, fine, but let's get something committed and move on. I think we understand what needs to be fixed here now, and I'd like to do get that done. If you don't want to do it or don't have time to do it, I'll pick it up again, but let's not let this keep dragging out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers