On 2019-03-07 15:25:34 +1300, David Rowley wrote: > On Thu, 7 Mar 2019 at 11:37, Andres Freund <and...@anarazel.de> wrote: > > > > On 2019-03-07 11:31:15 +1300, David Rowley wrote: > > > Do you think it's fine to reword the docs to make this point more > > > clear, or do you see this as a fundamental problem with the patch? > > > > Hm, both? I mean I wouldn't necessarily characterize it as "fundamental" > > problem, but ... > > Okay, so if I understand you correctly, you're complaining about the > fact that if the user does: > > CREATE TABLE p (a int) PARTITION BY LIST(a) TABLESPACE pg_default; > > that the user intended that all future partitions go to pg_default and > not whatever default_tablespace is set to at the time?
Correct. And also, conversely, if default_tablespace was set to frakbar at the time of CREATE TABLE, but no explicit TABLESPACE was provided, that that should *not* be the default for new partitions; rather default_tablespace should be consulted again. > If I understand what you're saying correctly, then the listp1_a_idx > should have been created in pg_default since that's what the default > partitioned index tablespace was set to. That's how I understand the intent of the user yes. > > I don't think the argument that the user intended to explicitly set a > > tablespace holds much water if it was just set via default_tablespace, > > rather than an explicit TABLESPACE. I think iff you really want > > something like this feature, you'd have to mark a partition's > > reltablespace as 0 unless an *explicit* assignment of the tablespace > > happened. In which case you also would need to explicitly emit a > > TABLESPACE for the partitioned table in pg_dump, to restore that. > > I think emitting an explicit tablespace in pg_dump for partitioned > tables (when non-zero) might have issues for pg_restore's > --no-tablespaces option. Yea, there'd probably need to be handling in pg_backup_archiver.c or such, not sure how to do that best. Greetings, Andres Freund
