Re: partition tree inspection functions
От | Amit Langote |
---|---|
Тема | Re: partition tree inspection functions |
Дата | |
Msg-id | 9a53564f-78aa-f34c-6b65-7c2367e432c4@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: partition tree inspection functions (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
On 2018/06/28 22:01, Ashutosh Bapat wrote: > On Thu, Jun 28, 2018 at 11:19 AM, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>> >>> It would have imagined that just creating a new file, say >>> partition_desc.sql or similar is nicer. >> >> How about partition_info.sql because they're testing partitioning >> information functions? partition_desc reminded me of PartitionDesc, an >> internal structure used in the partitioning codem which made me a bit >> uncomfortable. > > I think we should just add calls to these functions/views wherever we > are creating/altering or deleting objects to test a partition tree. I > serves two purposes, testing the objects created/modified and testing > the functions. Adding a new test file means we have to craft new > objects, which are sometimes readily available in some other test > files. Of course, we might find that certain cases are not covered by > existing tests, but then that also means that those cases are not > covered by object modification/creation tests as well. I think that makes sense. I couldn't assess by looking at tests for various functions listed on 9.25. System Information Functions whether there is some established practice about adding tests for them and/or about where to put them. For this particular set of functions, insert.sql may be a good place as it has many tests involving multi-level partitioned tables. Thanks, Amit
В списке pgsql-hackers по дате отправления: