Re: partition tree inspection functions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: partition tree inspection functions
Date
Msg-id 9a53564f-78aa-f34c-6b65-7c2367e432c4@lab.ntt.co.jp
Whole thread Raw
In response to Re: partition tree inspection functions  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Capitalization of the name OpenSSL
Next
From: Haribabu Kommi
Date:
Subject: Re: Does logical replication supports cross platform servers?