On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> 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 0001.

Committed 0002 and 0003 together.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to