| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Hashed SAOP on composite type with non-hashable column errors at runtime |
| Date: | 2026-06-08 16:00:20 |
| Message-ID: | 570738.1780934420@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
> Now, hash_ok_operator and op_hashjoinable handle all four container-type
> equality operators. Side way is a C extension that lets you create a custom type
> that groups other types marked as HASHES.
Yeah, it's interesting to speculate about what we'd have to do to
allow extensions to invent new kinds of container types. Right now,
the knowledge of what kinds of containers there are is wired into
a bunch of places. This fix isn't adding any new places, just fixing
some places whose knowledge was incomplete. So I'm content with this
for today.
> Fixes in the lookup_type_cache related to the multirange type are also correct
> for me. As well as pg_operator.dat changes.
Thanks for reviewing; I pushed v1-0001 after a bit more
comment-smithing.
>> I'm also unexcited about your 0002 and 0003.
> I understand about 0003, but what is the problem with 0002?
Let me rephrase that: 0002 is a new feature and hence out of scope
at this point in the development cycle. If you want to start a
new thread proposing that for v20, go right ahead.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-06-08 12:31:36 | RE: Logical replication initialization time depends dramatically on the publication "schema" size |