From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pgsql: Generalize hash and ordering support in amapi |
Date: | 2025-03-04 16:46:01 |
Message-ID: | 1789fe14-c19d-4025-9201-0eb8faa0840b@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 27.02.25 23:17, Mark Dilger wrote:
> The logic in equality_ops_are_compatible() was trusting that equality
> operators found in an opfamily for btree or hash were ok, but not
> trusting operators found in opfamilies of other AMs. Now, after the
> patch, other AMs can be marked as suitable. That's really the core of
> what the flag means: "Can the system trust that equality operators
> found in opfamilies of the AM are well-behaved", or something like
> that.
Yeah, what might be a good English identifier for that?
> I also object strongly to the fact that the comments for
> equality_ops_are_compatible and comparison_ops_are_compatible
> were not modified:
>
> * This is trivially true if they are the same operator. Otherwise,
> * we look to see if they can be found in the same btree or hash
> opfamily.
>
> * This is trivially true if they are the same operator. Otherwise,
> * we look to see if they can be found in the same btree opfamily.
>
> I agree these comments need updating.
Mark, can you suggest updated wording for those?
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2025-03-04 17:23:49 | Re: pgsql: Generalize hash and ordering support in amapi |
Previous Message | Fujii Masao | 2025-03-04 15:00:19 | pgsql: Add regression tests for pg_stat_progress_copy.tuples_skipped. |