1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
2003-11-09 22:30:38 +01:00
|
|
|
* scankey.c
|
|
|
|
* scan key support code
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/access/common/scankey.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "postgres.h"
|
1996-10-19 06:51:44 +02:00
|
|
|
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "access/skey.h"
|
2011-03-26 23:28:40 +01:00
|
|
|
#include "catalog/pg_collation.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
1999-02-14 00:22:53 +01:00
|
|
|
* ScanKeyEntryInitialize
|
2003-11-09 22:30:38 +01:00
|
|
|
* Initializes a scan key entry given all the field values.
|
2007-04-07 00:33:43 +02:00
|
|
|
* The target procedure is specified by OID (but can be invalid
|
2010-01-01 22:53:49 +01:00
|
|
|
* if SK_SEARCHNULL or SK_SEARCHNOTNULL is set).
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2003-11-09 22:30:38 +01:00
|
|
|
* Note: CurrentMemoryContext at call should be as long-lived as the ScanKey
|
|
|
|
* itself, because that's what will be used for any subsidiary info attached
|
|
|
|
* to the ScanKey's FmgrInfo record.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
ScanKeyEntryInitialize(ScanKey entry,
|
2003-11-09 22:30:38 +01:00
|
|
|
int flags,
|
1996-07-09 08:22:35 +02:00
|
|
|
AttrNumber attributeNumber,
|
2003-11-09 22:30:38 +01:00
|
|
|
StrategyNumber strategy,
|
2003-11-12 22:15:59 +01:00
|
|
|
Oid subtype,
|
2011-03-26 23:28:40 +01:00
|
|
|
Oid collation,
|
1996-07-09 08:22:35 +02:00
|
|
|
RegProcedure procedure,
|
2003-11-12 22:15:59 +01:00
|
|
|
Datum argument)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
entry->sk_flags = flags;
|
|
|
|
entry->sk_attno = attributeNumber;
|
2003-11-09 22:30:38 +01:00
|
|
|
entry->sk_strategy = strategy;
|
2003-11-12 22:15:59 +01:00
|
|
|
entry->sk_subtype = subtype;
|
2011-04-13 01:19:24 +02:00
|
|
|
entry->sk_collation = collation;
|
2003-11-12 22:15:59 +01:00
|
|
|
entry->sk_argument = argument;
|
2007-04-07 00:33:43 +02:00
|
|
|
if (RegProcedureIsValid(procedure))
|
2011-03-26 23:28:40 +01:00
|
|
|
{
|
2007-04-07 00:33:43 +02:00
|
|
|
fmgr_info(procedure, &entry->sk_func);
|
2011-03-26 23:28:40 +01:00
|
|
|
}
|
2007-04-07 00:33:43 +02:00
|
|
|
else
|
|
|
|
{
|
2010-01-01 22:53:49 +01:00
|
|
|
Assert(flags & (SK_SEARCHNULL | SK_SEARCHNOTNULL));
|
2007-04-07 00:33:43 +02:00
|
|
|
MemSet(&entry->sk_func, 0, sizeof(entry->sk_func));
|
|
|
|
}
|
2003-11-12 22:15:59 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ScanKeyInit
|
|
|
|
* Shorthand version of ScanKeyEntryInitialize: flags and subtype
|
2011-03-26 23:28:40 +01:00
|
|
|
* are assumed to be zero (the usual value), and collation is defaulted.
|
2003-11-12 22:15:59 +01:00
|
|
|
*
|
|
|
|
* This is the recommended version for hardwired lookups in system catalogs.
|
|
|
|
* It cannot handle NULL arguments, unary operators, or nondefault operators,
|
|
|
|
* but we need none of those features for most hardwired lookups.
|
|
|
|
*
|
Make collation-aware system catalog columns use "C" collation.
Up to now we allowed text columns in system catalogs to use collation
"default", but that isn't really safe because it might mean something
different in template0 than it means in a database cloned from template0.
In particular, this could mean that cloned pg_statistic entries for such
columns weren't entirely valid, possibly leading to bogus planner
estimates, though (probably) not any outright failures.
In the wake of commit 5e0928005, a better solution is available: if we
label such columns with "C" collation, then their pg_statistic entries
will also use that collation and hence will be valid independently of
the database collation.
This also provides a cleaner solution for indexes on such columns than
the hack added by commit 0b28ea79c: the indexes will naturally inherit
"C" collation and don't have to be forced to use text_pattern_ops.
Also, with the planned improvement of type "name" to be collation-aware,
this policy will apply cleanly to both text and name columns.
Because of the pg_statistic angle, we should also apply this policy
to the tables in information_schema. This patch does that by adjusting
information_schema's textual domain types to specify "C" collation.
That has the user-visible effect that order-sensitive comparisons to
textual information_schema view columns will now use "C" collation
by default. The SQL standard says that the collation of those view
columns is implementation-defined, so I think this is legal per spec.
At some point this might allow for translation of such comparisons
into indexable conditions on the underlying "name" columns, although
additional work will be needed before that can happen.
Discussion: https://postgr.es/m/19346.1544895309@sss.pgh.pa.us
2018-12-18 18:48:15 +01:00
|
|
|
* We set collation to C_COLLATION_OID always. This is the correct value
|
|
|
|
* for all collation-aware columns in system catalogs, and it will be ignored
|
|
|
|
* for other column types, so it's not worth trying to be more finicky.
|
2011-03-26 23:28:40 +01:00
|
|
|
*
|
2003-11-12 22:15:59 +01:00
|
|
|
* Note: CurrentMemoryContext at call should be as long-lived as the ScanKey
|
|
|
|
* itself, because that's what will be used for any subsidiary info attached
|
|
|
|
* to the ScanKey's FmgrInfo record.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ScanKeyInit(ScanKey entry,
|
|
|
|
AttrNumber attributeNumber,
|
|
|
|
StrategyNumber strategy,
|
|
|
|
RegProcedure procedure,
|
|
|
|
Datum argument)
|
|
|
|
{
|
|
|
|
entry->sk_flags = 0;
|
|
|
|
entry->sk_attno = attributeNumber;
|
|
|
|
entry->sk_strategy = strategy;
|
|
|
|
entry->sk_subtype = InvalidOid;
|
Make collation-aware system catalog columns use "C" collation.
Up to now we allowed text columns in system catalogs to use collation
"default", but that isn't really safe because it might mean something
different in template0 than it means in a database cloned from template0.
In particular, this could mean that cloned pg_statistic entries for such
columns weren't entirely valid, possibly leading to bogus planner
estimates, though (probably) not any outright failures.
In the wake of commit 5e0928005, a better solution is available: if we
label such columns with "C" collation, then their pg_statistic entries
will also use that collation and hence will be valid independently of
the database collation.
This also provides a cleaner solution for indexes on such columns than
the hack added by commit 0b28ea79c: the indexes will naturally inherit
"C" collation and don't have to be forced to use text_pattern_ops.
Also, with the planned improvement of type "name" to be collation-aware,
this policy will apply cleanly to both text and name columns.
Because of the pg_statistic angle, we should also apply this policy
to the tables in information_schema. This patch does that by adjusting
information_schema's textual domain types to specify "C" collation.
That has the user-visible effect that order-sensitive comparisons to
textual information_schema view columns will now use "C" collation
by default. The SQL standard says that the collation of those view
columns is implementation-defined, so I think this is legal per spec.
At some point this might allow for translation of such comparisons
into indexable conditions on the underlying "name" columns, although
additional work will be needed before that can happen.
Discussion: https://postgr.es/m/19346.1544895309@sss.pgh.pa.us
2018-12-18 18:48:15 +01:00
|
|
|
entry->sk_collation = C_COLLATION_OID;
|
1996-07-09 08:22:35 +02:00
|
|
|
entry->sk_argument = argument;
|
1998-01-15 20:46:37 +01:00
|
|
|
fmgr_info(procedure, &entry->sk_func);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2001-10-07 01:21:45 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ScanKeyEntryInitializeWithInfo
|
|
|
|
* Initializes a scan key entry using an already-completed FmgrInfo
|
|
|
|
* function lookup record.
|
|
|
|
*
|
2003-11-09 22:30:38 +01:00
|
|
|
* Note: CurrentMemoryContext at call should be as long-lived as the ScanKey
|
|
|
|
* itself, because that's what will be used for any subsidiary info attached
|
|
|
|
* to the ScanKey's FmgrInfo record.
|
2001-10-07 01:21:45 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
ScanKeyEntryInitializeWithInfo(ScanKey entry,
|
2003-11-09 22:30:38 +01:00
|
|
|
int flags,
|
2001-10-07 01:21:45 +02:00
|
|
|
AttrNumber attributeNumber,
|
2003-11-09 22:30:38 +01:00
|
|
|
StrategyNumber strategy,
|
2003-11-12 22:15:59 +01:00
|
|
|
Oid subtype,
|
2011-03-26 23:28:40 +01:00
|
|
|
Oid collation,
|
2001-10-07 01:21:45 +02:00
|
|
|
FmgrInfo *finfo,
|
2003-11-12 22:15:59 +01:00
|
|
|
Datum argument)
|
2001-10-07 01:21:45 +02:00
|
|
|
{
|
|
|
|
entry->sk_flags = flags;
|
|
|
|
entry->sk_attno = attributeNumber;
|
2003-11-09 22:30:38 +01:00
|
|
|
entry->sk_strategy = strategy;
|
2003-11-12 22:15:59 +01:00
|
|
|
entry->sk_subtype = subtype;
|
2011-04-13 01:19:24 +02:00
|
|
|
entry->sk_collation = collation;
|
2001-10-07 01:21:45 +02:00
|
|
|
entry->sk_argument = argument;
|
2003-11-09 22:30:38 +01:00
|
|
|
fmgr_info_copy(&entry->sk_func, finfo, CurrentMemoryContext);
|
2011-02-08 22:04:18 +01:00
|
|
|
}
|