diff options
| author | Peter Eisentraut <peter@eisentraut.org> | 2025-04-06 14:43:51 +0200 |
|---|---|---|
| committer | Peter Eisentraut <peter@eisentraut.org> | 2025-04-06 14:43:51 +0200 |
| commit | a8025f544854ad8b865c6b4509030ee84aa8f4a0 (patch) | |
| tree | 845091557eeb98a01ef6ce7ca0e26315f67e8cfc /src/backend/parser/parse_clause.c | |
| parent | 3a1a7c5a7071c75676c15b26e242c7df17560bd1 (diff) | |
| download | postgresql-a8025f544854ad8b865c6b4509030ee84aa8f4a0.tar.gz postgresql-a8025f544854ad8b865c6b4509030ee84aa8f4a0.zip | |
Relax ordering-related hardcoded btree requirements in planning
There were several places in ordering-related planning where a
requirement for btree was hardcoded but an amcanorder index could
suffice. This fixes that. We just need to do the necessary mapping
between strategy numbers and compare types and adjust some related
APIs so that this works independent of btree strategy numbers. For
instance, non-btree amcanorder indexes can now be used to support
sorting and merge joins. Also, predtest.c works independent of btree
strategy numbers now.
To avoid performance regressions, some details on btree and other
built-in index types are still hardcoded as shortcuts, but other index
types now have access to the same features by providing the required
flags and callbacks.
Author: Mark Dilger <mark.dilger@enterprisedb.com>
Co-authored-by: Peter Eisentraut <peter@eisentraut.org>
Discussion: https://www.postgresql.org/message-id/flat/E72EAA49-354D-4C2E-8EB9-255197F55330@enterprisedb.com
Diffstat (limited to 'src/backend/parser/parse_clause.c')
| -rw-r--r-- | src/backend/parser/parse_clause.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c index 2e64fcae7b2..9f20a70ce13 100644 --- a/src/backend/parser/parse_clause.c +++ b/src/backend/parser/parse_clause.c @@ -2915,7 +2915,7 @@ transformWindowDefinitions(ParseState *pstate, { SortGroupClause *sortcl; Node *sortkey; - int16 rangestrategy; + CompareType rangecmptype; if (list_length(wc->orderClause) != 1) ereport(ERROR, @@ -2928,7 +2928,7 @@ transformWindowDefinitions(ParseState *pstate, if (!get_ordering_op_properties(sortcl->sortop, &rangeopfamily, &rangeopcintype, - &rangestrategy)) + &rangecmptype)) elog(ERROR, "operator %u is not a valid ordering operator", sortcl->sortop); /* Record properties of sort ordering */ |