On Wed, Apr 11, 2018 at 4:54 PM, Michael Paquier <mich...@paquier.xyz>

> On Wed, Apr 11, 2018 at 12:52:06PM -0400, Keith Fiske wrote:
> > Any chance of this being an inheritable property that can simply be
> > overridden if the TABLESPACE flag is set when creating a child table? If
> > it's not set, just set the tablespace to whatever was set for the parent.
> I am wondering how you would actually design that without some kind of
> unintuitive behavior for the end user as for some applications a set of
> child partitions sometimes take advantage of the fact that they are on
> separate tablespaces.  Hence why not relying on default_tablespace
> instead when creating the partition set, or use a function wrapper which
> enforces the tablespace when the partition is created?
> --
> Michael

To me the current behavior is even more unintuitive. You tell it to put the
parent table in a specific tablespace and it completely ignores the option
and puts it in the default. Then when you go create children without
specifying a tablespace, you don't see it going where you thought it would
based on the parent's creation statement. Yes, you can tell each child
where to go, but why not have at least a basic mechanism for setting a
single tablespace value for a partition set into the parent itself the same
way we're doing with indexes?

If you set the tablespace you want a partition set to be in by setting that
on that parent, I think that's pretty intuitive. If you want children to be
in a different tablespace than the partition's default, then you can tell
it that at child creation.

Having to rely on custom written function to enforce just basic tablespace
rules seems to be overcomplicating it to me.

Keith Fiske
Senior Database Engineer
Crunchy Data - http://crunchydata.com

Reply via email to