Hi,
On 2019-03-07 11:31:15 +1300, David Rowley wrote:
> On Thu, 7 Mar 2019 at 05:17, Andres Freund <andres@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
