Subject: Re: Hash support for row types
To: Andres Freund <andres@anarazel.de>
References: <38eccd35-4e2d-6767-1b3c-dada1eac3124@2ndquadrant.com>
 <20201019233234.r6lyxbvdg5s77rvd@alap3.anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <e88b1974-5987-9ae8-7e54-7d66f54751cb@2ndquadrant.com>
Date: Tue, 20 Oct 2020 17:10:24 +0200
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: <20201019233234.r6lyxbvdg5s77rvd@alap3.anarazel.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2020-10-20 01:32, Andres Freund wrote:
> How does this deal with row types with a field that doesn't have a hash
> function? Erroring out at runtime could cause queries that used to
> succeed, e.g. because all fields have btree ops, to fail, if we just have
> a generic unconditionally present hash opclass?  Is that an OK
> "regression"?

Good point.  There is actually code in the type cache that is supposed 
to handle that, so I'll need to adjust that.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services