| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> | 
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Cc: | Andres Freund <andres(at)anarazel(dot)de> | 
| Subject: | Re: Hash support for row types | 
| Date: | 2020-10-23 07:49:15 | 
| Message-ID: | f7195e93-ab9d-01f0-1140-361aece79248@2ndquadrant.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2020-10-20 17:10, Peter Eisentraut wrote:
> 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.
Here is an updated patch with the type cache integration added.
To your point, this now checks each fields hashability before 
considering a row type as hashable.  It can still have run-time errors 
for untyped record datums, but that's not something we can do anything 
about.
-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| Attachment | Content-Type | Size | 
|---|---|---|
| v2-0001-Hash-support-for-row-types.patch | text/plain | 26.5 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yugo NAGATA | 2020-10-23 07:57:26 | Re: Implementing Incremental View Maintenance | 
| Previous Message | Michael Paquier | 2020-10-23 07:37:18 | Re: Tab complete for alter table rls |