database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-29 10:41:53 +03:00
Code Activity

Pass collations to functions in FunctionCallInfoData, not FmgrInfo.

Browse Source 
Since collation is effectively an argument, not a property of the function,
FmgrInfo is really the wrong place for it; and this becomes critical in
cases where a cached FmgrInfo is used for varying purposes that might need
different collation settings.  Fix by passing it in FunctionCallInfoData
instead.  In particular this allows a clean fix for bug #5970 (record_cmp
not working).  This requires touching a bit more code than the original
method, but nobody ever thought that collations would not be an invasive
patch...
This commit is contained in:
Tom Lane
2011-04-12 19:19:24 -04:00
parent 88543ecfec
commit d64713df7e
49 changed files with 552 additions and 418 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/include/access/skey.h
View File

@ -52,16 +52,16 @@ typedef uint16 StrategyNumber;
* the operator. When using a ScanKey in a heap scan, these fields are not
* used and may be set to InvalidStrategy/InvalidOid.
*
* If the operator is collation-sensitive, sk_func.fn_collation must be set
* If the operator is collation-sensitive, sk_collation must be set
* correctly as well.
*
* A ScanKey can also represent a condition "column IS NULL" or "column
* IS NOT NULL"; these cases are signaled by the SK_SEARCHNULL and
* SK_SEARCHNOTNULL flag bits respectively. The argument is always NULL,
* and the sk_strategy, sk_subtype, and sk_func fields are not used (unless
* set by the index AM). Currently, SK_SEARCHNULL and SK_SEARCHNOTNULL are
* supported only for index scans, not heap scans; and not all index AMs
* support them.
* and the sk_strategy, sk_subtype, sk_collation, and sk_func fields are
* not used (unless set by the index AM). Currently, SK_SEARCHNULL and
* SK_SEARCHNOTNULL are supported only for index scans, not heap scans;
* and not all index AMs support them.
*
* A ScanKey can also represent an ordering operator invocation, that is
* an ordering requirement "ORDER BY indexedcol op constant". This looks
@ -70,8 +70,8 @@ typedef uint16 StrategyNumber;
*
* Note: in some places, ScanKeys are used as a convenient representation
* for the invocation of an access method support procedure. In this case
* sk_strategy/sk_subtype are not meaningful, and sk_func may refer to a
* function that returns something other than boolean.
* sk_strategy/sk_subtype are not meaningful (but sk_collation can be); and
* sk_func may refer to a function that returns something other than boolean.
*/
typedef struct ScanKeyData
{
@ -79,6 +79,7 @@ typedef struct ScanKeyData
AttrNumber sk_attno; /* table or index column number */
StrategyNumber sk_strategy; /* operator strategy number */
Oid sk_subtype; /* strategy subtype */
Oid sk_collation; /* collation to use, if needed */
FmgrInfo sk_func; /* lookup info for function to call */
Datum sk_argument; /* data to compare */
} ScanKeyData;
@ -99,7 +100,7 @@ typedef ScanKeyData *ScanKey;
* sk_attno = index column number for leading column of row comparison
* sk_strategy = btree strategy code for semantics of row comparison
* (ie, < <= > or >=)
* sk_subtype, sk_func: not used
* sk_subtype, sk_collation, sk_func: not used
* sk_argument: pointer to subsidiary ScanKey array
* If the header is part of a ScanKey array that's sorted by attno, it
* must be sorted according to the leading column number.