On Thu, Feb 23, 2017 at 11:13 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > My argument was that CREATE INDEX is expected to just work on tables > at present, so should also just work on partitioned tables. Without > that, the reality is people will need to write scripts.
Really? What about postgres_fdw? Even if that counter-example didn't exist, I'd still disagree. People may expect that CREATE INDEX should just work, but that expectation is not as general as you suggest. Otherwise, I doubt we'd be talking about it at all. > I don't see how that relates to the desire for multiple index options, > since one of them would need to be the default and we could provide > one in this release, one in the next etc.. You didn't say any of that until now. And besides, I think that global indexes make a lot more sense as a default. You seem to be saying that a simple CREATE INDEX could be interpreted as meaning one or the other of those two behaviors just as easily (global index vs. create an index on each partition). I don't think it's a good idea to try to meet any general "just works" expectation if what you actually get does not fit the intuition of almost all users. "Just don't show me an error" seems like a bad design goal, especially for a utility statement. > The current design has assumed many things, leading me to question > what else has been assumed. > > Challenging those assumptions is important and has been upheld. I agree. The irony is that in so doing, you yourself make your own assumptions, confusing everyone, and making it harder to act on your feedback. You did make some reasonable points, IMV. > I've seen many patches rejected because they do not contain the > desired feature set, yet. Obviously that general principle is not under discussion. My point, of course, was that it seems pretty clear to me that this is on the right side of that fence. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
