> On Apr 12, 2018, at 3:10 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > Robert Haas wrote: >> On Thu, Apr 12, 2018 at 2:40 PM, Jonathan S. Katz >> <jonathan.katz@excoventures.com> wrote: >>> If there are no strong objections I am going to add this to the “Older Bugs” >>> section of Open Items in a little bit. >> >> I strongly object. This is not a bug. The TABLESPACE clause doing >> exactly what it was intended to do, which is determine where all of >> the storage associated with the partitioned table itself goes. It so >> happens that there is no storage, so now somebody would like to >> repurpose the same option to do something different. That's fine, but >> it doesn't make the current behavior wrong. And we're certainly not >> going to back-patch a behavior change like that.
Behavior-wise it’s certainly a bug: you add a TABLESPACE on the parent table, and that property is not passed down to the children, which is not what the user expects. At a minimum, if we don’t back patch it, we probably need to update the documentation to let people know. > Keep in mind that we do not offer any promises to fix items listed in > the Older Bugs section; as I said elsewhere, it's mostly a dumping > ground for things that get ignored later. I think it's fine to add it > there, if Jon wants to keep track of it, on the agreement that it will > probably not lead to a backpatched fix.
Per an off-list discussion, it does not make sense to back patch but it does make sense to try to get it into 11 as part of making things more stable.
Perhaps as a short-term fix, we update the docs to let users know that if you put a TABLESPACE on the parent table it does not get passed down to the children? Jonathan
I also think it's rather confusing that, even though there is technically no data storage going on with the parent, that the parent itself does not get placed in the tablespace given to the creation command. Just completely ignoring a flag given to a command with zero feedback is my biggest complaint on this. If it's going to be ignored, at least giving some sort of feedback (kind of like long name truncation does) would be useful here and should be considered for back-patching to 10.
