On Wed, Apr 11, 2018 at 4:54 PM, Michael Paquier <michael@paquier.xyz> wrote:
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.
