Re: Documentation improvements for partitioning

On 13 February 2017 at 05:21, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:

>> Few points from tests
>>
>> * "ERROR: cannot create index on partitioned table "measurement_year_month""
>> is misleading because you can create indexes on partitions
>
> Do you mean that this should not cause an error at all, but create the
> specified index on partitions as part of running the command? Should the
> code to handle that be part of this release?

Sounds fairly basic to me. If you don't support this, then presumably
every ORM, pgAdmin etc will all be broken.

And 1000 people will need to write a script that does what we could do
easily in a loop internally.

At present you haven't even documented how you'd do this.

I see you might want to create an index on a subset of partitions, but
I expect that you've thought of that and have a proposal for syntax
that allows it. Though the default should be that CREATE INDEX just
works.

> Or do you simply mean that we should rewrite the error message and/or add
> a HINT asking to create the index on partitions instead?

You could

>> * It's very weird you can't DROP a partitioned table. I think you need
>> to add dependencies.
>
> Do you mean it should be possible to DROP a partitioned table without
> needing to specify CASCADE? Currently, same thing happens for a
> partitioned table as will for a inheritance parent.

If we wanted them to act identically we wouldn't have any need for a
new feature at all, so clearly that doesn't make sense as an argument.

If I issue DROP TABLE elsewhere, it doesn't refuse to drop because it
has indexes, sequences etc on it. So why should it just because it has
partitions? Most especially if they were created automatically for me
in the first place. I might just understand that running ATTACH TABLE
might change that viewpoint.

I'm pretty sure DROP TABLE and CREATE INDEX are fairly basic
expectations from users about how tables should work, partitioned or
otherwise.

It leaves me asking what else is missing.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services