Subject: Re: get_constraint_index() and conindid
To: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
References: <4688d55c-9a2e-9a5a-d166-5f24fe0bf8db@enterprisedb.com>
 <CAEze2WjBDFL3tSUTkaijZOa-pg3k_VcmyQzMXtW-qWQNfj-SKw@mail.gmail.com>
 <3260997.1607452119@sss.pgh.pa.us> <X9BwvuLuWJrIreQE@paquier.xyz>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Organization: EnterpriseDB
Message-ID: <2ddf07fc-883f-f1c4-dfbc-e977a0162e66@enterprisedb.com>
Date: Wed, 9 Dec 2020 15:50:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <X9BwvuLuWJrIreQE@paquier.xyz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-12-09 07:37, Michael Paquier wrote:
>>> Only thing I could think of is that it maybe could use a (small)
>>> comment in the message on that/why get_constraint_index is moved to
>>> utils/lsyscache from catalog/dependency, as that took me some time to
>>> understand.
>>
>> commit message could reasonably say that maybe, but I don't think we
>> need to memorialize it in a comment.  lsyscache.c *is* where one
>> would expect to find a simple catalog-field-fetch function like this.
>> The previous implementation was not that, so it didn't belong there.
> 
> Agreed.

Thanks, I committed it with an expanded commit message.

After further inspection, I'm not going to do anything about the nearby 
get_index_constraint() at this item.  The current implementation can use 
an index on pg_depend.  A scan of pg_constraint has no index available.