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: http://www.postgresql.org/mailpref/pgsql-hackers
