On 2018/04/13 1:47, Robert Haas wrote: > On Wed, Apr 11, 2018 at 8:35 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: >> Here's an idea. Why don't we move the function/opclass creation lines >> to insert.sql, without the DROPs, and use the same functions/opclasses >> in the three tests insert.sql, alter_table.sql, hash_part.sql and >> partition_prune.sql, i.e. not recreate what are essentially the same >> objects three times? This also leaves them around for the pg_upgrade >> test, which is not a bad thing. > > That sounds good, but maybe we should go further and move the > partitioning tests out of generically-named things like insert.sql > altogether and have test names that actually mention partitioning.
Do you mean to do that for *all* files that have tests exercising some partitioning code, even if it's just one test? I can see that tests in at least some of them could be put into their own partition_ file as follows: partition_insert (including tests in insert_conflict) partition_update partition_triggers partition_indexing (indexing.sql added when partitioned indexes went in) partition_ddl (for the tests in create_table and alter_table) That leaves: cluster create_index (one test here could be moved to partition_indexing?) foreign_data (could be moved to partition_ddl?) foreign_key (could be moved to partition_ddl?) hash_part (leave alone, because already contains 'part' in the name?) identity join plancache plpgsql publication rowsecurity rules stats_ext tablesample truncate updatable_views vacuum What about the tests in inherit.sql that start with: -- -- Check that constraint exclusion works correctly with partitions using -- implicit constraints generated from the partition bound information. -- Maybe, just move all of them to partition_prune.sql, because we no longer use constraint exclusion for pruning? Thanks, Amit
