Hi, On 2019-03-07 11:31:15 +1300, David Rowley wrote: > On Thu, 7 Mar 2019 at 05:17, Andres Freund <and...@anarazel.de> wrote: > > I'm also concerned that the the current catalog representation isn't > > right. As I said: > > > > > I also find it far from clear that: > > > <listitem> > > > <para> > > > The <replaceable class="parameter">tablespace_name</replaceable> is > > > the name > > > of the tablespace in which the new table is to be created. > > > If not specified, > > > <xref linkend="guc-default-tablespace"/> is consulted, or > > > <xref linkend="guc-temp-tablespaces"/> if the table is temporary. > > > For > > > partitioned tables, since no storage is required for the table > > > itself, > > > the tablespace specified here only serves to mark the default > > > tablespace > > > for any newly created partitions when no other tablespace is > > > explicitly > > > specified. > > > </para> > > > </listitem> > > > is handled correctly. The above says that the *specified* tablespaces - > > > which seems to exclude the default tablespace - is what's going to > > > determine what partitions use as their default tablespace. But in fact > > > that's not true, the partitioned table's pg_class.retablespace is set to > > > what default_tablespaces was at the time of the creation. > > 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 ... 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. Greetings, Andres Freund
