On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote
> On 2017/03/07 14:04, Tom Lane wrote:
>> Amit Langote <langote_amit...@lab.ntt.co.jp> writes:
>>> Also, I found out that alter_table.sql mistakenly forgot to drop
>>> partitioned table "p1". Patch 0002 takes care of that.
>> While that might or might not have been intentional, I think it's an
>> astoundingly bad idea to not leave any partitioned tables behind in
>> the final state of the regression database. Doing so would likely
>> have meant that this particular bug evaded detection for much longer
>> than it did. Moreover, it would mean that the pg_upgrade test would
>> have exactly no coverage of partitioned cases.
> That's true. Should have been apparent to me.
>> Therefore, there should definitely be a partitioned table, hopefully with
>> a less generic name than "p1", in the final regression DB state. Whether
>> this particular one from alter_table.sql is a good candidate, I dunno.
>> But let's not drop it without adding a better-thought-out replacement.
> OK, let's drop p1 in alter_table.sql. I think a partitioned table created
> in insert.sql is a good candidate to keep around after having it renamed,
> which patch 0003 does.
Committed 0002 and 0003 together.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: