On Fri, Apr 13, 2018 at 7:45 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > 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) >
We haven't generally created test files specific to a table type for example temporary tables or unlogged tables, instead have created files by SQL commands. But then that's not true for indexes; we have separate files for indexes and we also have separate file for materialized views and also for various data types. So, our test file organization seems to have cut across of SQL commands and object types. But partitioning seems an area large enough to have files of its own; we already have partition_join and partition_aggregate. Do we want to move to a directory based organization for tests also, where sql/ expected/ will have directories within them for various types of objects like partitioned tables, indexes, regular tables, datatypes etc. and each of those will have files organized by sql commands? An immediate question arises as to where to add the files which exercises a mixture of objects; may be in a directory corresponding to the primary object like materialized views over partitioned tables, would fit materialized view (or just views?) directory. Whatever organization we want to use, it should be easy to find testcases for relevant functionality e.g. all tests for partitioned tables or all alter table command tests. > 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? I think we need to have some testcases somwhere to test constraint exclusion on partitions and partitioned tables, those do not necessarily fit partition pruning. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
