Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#----------------------------------------------------------------------
|
|
|
|
#
|
|
|
|
# pg_opclass.dat
|
2018-04-19 23:14:09 +02:00
|
|
|
# Initial contents of the pg_opclass system catalog.
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
#
|
2019-01-02 18:44:25 +01:00
|
|
|
# Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
#
|
|
|
|
# src/include/catalog/pg_opclass.dat
|
|
|
|
#
|
|
|
|
#----------------------------------------------------------------------
|
|
|
|
|
|
|
|
[
|
|
|
|
|
|
|
|
# Note: we hard-wire an OID only for a few entries that have to be explicitly
|
|
|
|
# referenced in the C code or in built-in catalog entries. The rest get OIDs
|
|
|
|
# assigned on-the-fly during initdb.
|
|
|
|
|
|
|
|
{ opcmethod => 'btree', opcname => 'array_ops', opcfamily => 'btree/array_ops',
|
|
|
|
opcintype => 'anyarray' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'array_ops', opcfamily => 'hash/array_ops',
|
|
|
|
opcintype => 'anyarray' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'bit_ops', opcfamily => 'btree/bit_ops',
|
|
|
|
opcintype => 'bit' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'bool_ops', opcfamily => 'btree/bool_ops',
|
|
|
|
opcintype => 'bool' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'bpchar_ops',
|
|
|
|
opcfamily => 'btree/bpchar_ops', opcintype => 'bpchar' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'bpchar_ops', opcfamily => 'hash/bpchar_ops',
|
|
|
|
opcintype => 'bpchar' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'bytea_ops', opcfamily => 'btree/bytea_ops',
|
|
|
|
opcintype => 'bytea' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'char_ops', opcfamily => 'btree/char_ops',
|
|
|
|
opcintype => 'char' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'char_ops', opcfamily => 'hash/char_ops',
|
|
|
|
opcintype => 'char' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'cidr_ops', opcfamily => 'btree/network_ops',
|
|
|
|
opcintype => 'inet', opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'cidr_ops', opcfamily => 'hash/network_ops',
|
|
|
|
opcintype => 'inet', opcdefault => 'f' },
|
|
|
|
{ oid => '3122', oid_symbol => 'DATE_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'date_ops',
|
|
|
|
opcfamily => 'btree/datetime_ops', opcintype => 'date' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'date_ops', opcfamily => 'hash/date_ops',
|
|
|
|
opcintype => 'date' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'float4_ops', opcfamily => 'btree/float_ops',
|
|
|
|
opcintype => 'float4' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'float4_ops', opcfamily => 'hash/float_ops',
|
|
|
|
opcintype => 'float4' },
|
|
|
|
{ oid => '3123', oid_symbol => 'FLOAT8_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'float8_ops', opcfamily => 'btree/float_ops',
|
|
|
|
opcintype => 'float8' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'float8_ops', opcfamily => 'hash/float_ops',
|
|
|
|
opcintype => 'float8' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'inet_ops', opcfamily => 'btree/network_ops',
|
|
|
|
opcintype => 'inet' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'inet_ops', opcfamily => 'hash/network_ops',
|
|
|
|
opcintype => 'inet' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'inet_ops', opcfamily => 'gist/network_ops',
|
|
|
|
opcintype => 'inet', opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'inet_ops',
|
|
|
|
opcfamily => 'spgist/network_ops', opcintype => 'inet' },
|
|
|
|
{ oid => '1979', oid_symbol => 'INT2_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'int2_ops', opcfamily => 'btree/integer_ops',
|
|
|
|
opcintype => 'int2' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'int2_ops', opcfamily => 'hash/integer_ops',
|
|
|
|
opcintype => 'int2' },
|
|
|
|
{ oid => '1978', oid_symbol => 'INT4_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'int4_ops', opcfamily => 'btree/integer_ops',
|
|
|
|
opcintype => 'int4' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'int4_ops', opcfamily => 'hash/integer_ops',
|
|
|
|
opcintype => 'int4' },
|
|
|
|
{ oid => '3124', oid_symbol => 'INT8_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'int8_ops', opcfamily => 'btree/integer_ops',
|
|
|
|
opcintype => 'int8' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'int8_ops', opcfamily => 'hash/integer_ops',
|
|
|
|
opcintype => 'int8' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'interval_ops',
|
|
|
|
opcfamily => 'btree/interval_ops', opcintype => 'interval' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'interval_ops',
|
|
|
|
opcfamily => 'hash/interval_ops', opcintype => 'interval' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'macaddr_ops',
|
|
|
|
opcfamily => 'btree/macaddr_ops', opcintype => 'macaddr' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'macaddr_ops',
|
|
|
|
opcfamily => 'hash/macaddr_ops', opcintype => 'macaddr' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'macaddr8_ops',
|
|
|
|
opcfamily => 'btree/macaddr8_ops', opcintype => 'macaddr8' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'macaddr8_ops',
|
|
|
|
opcfamily => 'hash/macaddr8_ops', opcintype => 'macaddr8' },
|
|
|
|
|
|
|
|
# Here's an ugly little hack to save space in the system catalog indexes.
|
|
|
|
# btree doesn't ordinarily allow a storage type different from input type;
|
|
|
|
# but cstring and name are the same thing except for trailing padding,
|
2024-05-01 03:23:25 +02:00
|
|
|
# so we choose to omit that within an index entry. Here we declare the
|
|
|
|
# btree opclass for name as using cstring storage type. This does require
|
|
|
|
# that we pad the cstring out with the full NAMEDATALEN bytes when performing
|
|
|
|
# index-only scans. See corresponding hacks in ExecInitIndexOnlyScan() and
|
|
|
|
# StoreIndexTuple().
|
2018-12-19 23:46:07 +01:00
|
|
|
{ opcmethod => 'btree', opcname => 'name_ops', opcfamily => 'btree/text_ops',
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
opcintype => 'name', opckeytype => 'cstring' },
|
|
|
|
|
2018-12-19 23:46:07 +01:00
|
|
|
{ opcmethod => 'hash', opcname => 'name_ops', opcfamily => 'hash/text_ops',
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
opcintype => 'name' },
|
|
|
|
{ oid => '3125', oid_symbol => 'NUMERIC_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'numeric_ops',
|
|
|
|
opcfamily => 'btree/numeric_ops', opcintype => 'numeric' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'numeric_ops',
|
|
|
|
opcfamily => 'hash/numeric_ops', opcintype => 'numeric' },
|
|
|
|
{ oid => '1981', oid_symbol => 'OID_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'oid_ops', opcfamily => 'btree/oid_ops',
|
|
|
|
opcintype => 'oid' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'oid_ops', opcfamily => 'hash/oid_ops',
|
|
|
|
opcintype => 'oid' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'oidvector_ops',
|
|
|
|
opcfamily => 'btree/oidvector_ops', opcintype => 'oidvector' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'oidvector_ops',
|
|
|
|
opcfamily => 'hash/oidvector_ops', opcintype => 'oidvector' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'record_ops',
|
|
|
|
opcfamily => 'btree/record_ops', opcintype => 'record' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'record_image_ops',
|
|
|
|
opcfamily => 'btree/record_image_ops', opcintype => 'record',
|
|
|
|
opcdefault => 'f' },
|
|
|
|
{ oid => '3126', oid_symbol => 'TEXT_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'text_ops', opcfamily => 'btree/text_ops',
|
|
|
|
opcintype => 'text' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'text_ops', opcfamily => 'hash/text_ops',
|
|
|
|
opcintype => 'text' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'time_ops', opcfamily => 'btree/time_ops',
|
|
|
|
opcintype => 'time' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'time_ops', opcfamily => 'hash/time_ops',
|
|
|
|
opcintype => 'time' },
|
|
|
|
{ oid => '3127', oid_symbol => 'TIMESTAMPTZ_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'timestamptz_ops',
|
|
|
|
opcfamily => 'btree/datetime_ops', opcintype => 'timestamptz' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'timestamptz_ops',
|
|
|
|
opcfamily => 'hash/timestamptz_ops', opcintype => 'timestamptz' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'timetz_ops',
|
|
|
|
opcfamily => 'btree/timetz_ops', opcintype => 'timetz' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'timetz_ops', opcfamily => 'hash/timetz_ops',
|
|
|
|
opcintype => 'timetz' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'varbit_ops',
|
|
|
|
opcfamily => 'btree/varbit_ops', opcintype => 'varbit' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'varchar_ops', opcfamily => 'btree/text_ops',
|
|
|
|
opcintype => 'text', opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'varchar_ops', opcfamily => 'hash/text_ops',
|
|
|
|
opcintype => 'text', opcdefault => 'f' },
|
|
|
|
{ oid => '3128', oid_symbol => 'TIMESTAMP_BTREE_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'timestamp_ops',
|
|
|
|
opcfamily => 'btree/datetime_ops', opcintype => 'timestamp' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'timestamp_ops',
|
|
|
|
opcfamily => 'hash/timestamp_ops', opcintype => 'timestamp' },
|
Fix up handling of nondeterministic collations with pattern_ops opclasses.
text_pattern_ops and its siblings can't be used with nondeterministic
collations, because they use the text_eq operator which will not behave
as bitwise equality if applied with a nondeterministic collation. The
initial implementation of that restriction was to insert a run-time test
in the related comparison functions, but that is inefficient, may throw
misleading errors, and will throw errors in some cases that would work.
It seems sufficient to just prevent the combination during CREATE INDEX,
so do that instead.
Lacking any better way to identify the opclasses involved, we need to
hard-wire tests for them, which requires hand-assigned values for their
OIDs, which forces a catversion bump because they previously had OIDs
that would be assigned automatically. That's slightly annoying in the
v12 branch, but fortunately we're not at rc1 yet, so just do it.
Back-patch to v12 where nondeterministic collations were added.
In passing, run make reformat-dat-files, which found some unrelated
whitespace issues (slightly different ones in HEAD and v12).
Peter Eisentraut, with small corrections by me
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
2019-09-21 22:29:17 +02:00
|
|
|
{ oid => '4217', oid_symbol => 'TEXT_BTREE_PATTERN_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'text_pattern_ops',
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
opcfamily => 'btree/text_pattern_ops', opcintype => 'text',
|
|
|
|
opcdefault => 'f' },
|
Fix up handling of nondeterministic collations with pattern_ops opclasses.
text_pattern_ops and its siblings can't be used with nondeterministic
collations, because they use the text_eq operator which will not behave
as bitwise equality if applied with a nondeterministic collation. The
initial implementation of that restriction was to insert a run-time test
in the related comparison functions, but that is inefficient, may throw
misleading errors, and will throw errors in some cases that would work.
It seems sufficient to just prevent the combination during CREATE INDEX,
so do that instead.
Lacking any better way to identify the opclasses involved, we need to
hard-wire tests for them, which requires hand-assigned values for their
OIDs, which forces a catversion bump because they previously had OIDs
that would be assigned automatically. That's slightly annoying in the
v12 branch, but fortunately we're not at rc1 yet, so just do it.
Back-patch to v12 where nondeterministic collations were added.
In passing, run make reformat-dat-files, which found some unrelated
whitespace issues (slightly different ones in HEAD and v12).
Peter Eisentraut, with small corrections by me
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
2019-09-21 22:29:17 +02:00
|
|
|
{ oid => '4218', oid_symbol => 'VARCHAR_BTREE_PATTERN_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'varchar_pattern_ops',
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
opcfamily => 'btree/text_pattern_ops', opcintype => 'text',
|
|
|
|
opcdefault => 'f' },
|
Fix up handling of nondeterministic collations with pattern_ops opclasses.
text_pattern_ops and its siblings can't be used with nondeterministic
collations, because they use the text_eq operator which will not behave
as bitwise equality if applied with a nondeterministic collation. The
initial implementation of that restriction was to insert a run-time test
in the related comparison functions, but that is inefficient, may throw
misleading errors, and will throw errors in some cases that would work.
It seems sufficient to just prevent the combination during CREATE INDEX,
so do that instead.
Lacking any better way to identify the opclasses involved, we need to
hard-wire tests for them, which requires hand-assigned values for their
OIDs, which forces a catversion bump because they previously had OIDs
that would be assigned automatically. That's slightly annoying in the
v12 branch, but fortunately we're not at rc1 yet, so just do it.
Back-patch to v12 where nondeterministic collations were added.
In passing, run make reformat-dat-files, which found some unrelated
whitespace issues (slightly different ones in HEAD and v12).
Peter Eisentraut, with small corrections by me
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
2019-09-21 22:29:17 +02:00
|
|
|
{ oid => '4219', oid_symbol => 'BPCHAR_BTREE_PATTERN_OPS_OID',
|
|
|
|
opcmethod => 'btree', opcname => 'bpchar_pattern_ops',
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
opcfamily => 'btree/bpchar_pattern_ops', opcintype => 'bpchar',
|
|
|
|
opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'money_ops', opcfamily => 'btree/money_ops',
|
|
|
|
opcintype => 'money' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'bool_ops', opcfamily => 'hash/bool_ops',
|
|
|
|
opcintype => 'bool' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'bytea_ops', opcfamily => 'hash/bytea_ops',
|
|
|
|
opcintype => 'bytea' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'tid_ops', opcfamily => 'btree/tid_ops',
|
|
|
|
opcintype => 'tid' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'xid_ops', opcfamily => 'hash/xid_ops',
|
|
|
|
opcintype => 'xid' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'cid_ops', opcfamily => 'hash/cid_ops',
|
|
|
|
opcintype => 'cid' },
|
2018-12-30 21:40:04 +01:00
|
|
|
{ opcmethod => 'hash', opcname => 'tid_ops', opcfamily => 'hash/tid_ops',
|
|
|
|
opcintype => 'tid' },
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
{ opcmethod => 'hash', opcname => 'text_pattern_ops',
|
|
|
|
opcfamily => 'hash/text_pattern_ops', opcintype => 'text',
|
|
|
|
opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'varchar_pattern_ops',
|
|
|
|
opcfamily => 'hash/text_pattern_ops', opcintype => 'text',
|
|
|
|
opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'bpchar_pattern_ops',
|
|
|
|
opcfamily => 'hash/bpchar_pattern_ops', opcintype => 'bpchar',
|
|
|
|
opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'aclitem_ops',
|
|
|
|
opcfamily => 'hash/aclitem_ops', opcintype => 'aclitem' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'box_ops', opcfamily => 'gist/box_ops',
|
|
|
|
opcintype => 'box' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'point_ops', opcfamily => 'gist/point_ops',
|
|
|
|
opcintype => 'point', opckeytype => 'box' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'poly_ops', opcfamily => 'gist/poly_ops',
|
|
|
|
opcintype => 'polygon', opckeytype => 'box' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'circle_ops', opcfamily => 'gist/circle_ops',
|
|
|
|
opcintype => 'circle', opckeytype => 'box' },
|
|
|
|
{ opcmethod => 'gin', opcname => 'array_ops', opcfamily => 'gin/array_ops',
|
|
|
|
opcintype => 'anyarray', opckeytype => 'anyelement' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'uuid_ops', opcfamily => 'btree/uuid_ops',
|
|
|
|
opcintype => 'uuid' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'uuid_ops', opcfamily => 'hash/uuid_ops',
|
|
|
|
opcintype => 'uuid' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'pg_lsn_ops',
|
|
|
|
opcfamily => 'btree/pg_lsn_ops', opcintype => 'pg_lsn' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'pg_lsn_ops', opcfamily => 'hash/pg_lsn_ops',
|
|
|
|
opcintype => 'pg_lsn' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'enum_ops', opcfamily => 'btree/enum_ops',
|
|
|
|
opcintype => 'anyenum' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'enum_ops', opcfamily => 'hash/enum_ops',
|
|
|
|
opcintype => 'anyenum' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'tsvector_ops',
|
|
|
|
opcfamily => 'btree/tsvector_ops', opcintype => 'tsvector' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'tsvector_ops',
|
|
|
|
opcfamily => 'gist/tsvector_ops', opcintype => 'tsvector',
|
|
|
|
opckeytype => 'gtsvector' },
|
|
|
|
{ opcmethod => 'gin', opcname => 'tsvector_ops',
|
|
|
|
opcfamily => 'gin/tsvector_ops', opcintype => 'tsvector',
|
|
|
|
opckeytype => 'text' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'tsquery_ops',
|
|
|
|
opcfamily => 'btree/tsquery_ops', opcintype => 'tsquery' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'tsquery_ops',
|
|
|
|
opcfamily => 'gist/tsquery_ops', opcintype => 'tsquery',
|
|
|
|
opckeytype => 'int8' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'range_ops', opcfamily => 'btree/range_ops',
|
|
|
|
opcintype => 'anyrange' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'range_ops', opcfamily => 'hash/range_ops',
|
|
|
|
opcintype => 'anyrange' },
|
|
|
|
{ opcmethod => 'gist', opcname => 'range_ops', opcfamily => 'gist/range_ops',
|
|
|
|
opcintype => 'anyrange' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'range_ops',
|
|
|
|
opcfamily => 'spgist/range_ops', opcintype => 'anyrange' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'box_ops', opcfamily => 'spgist/box_ops',
|
|
|
|
opcintype => 'box' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'quad_point_ops',
|
|
|
|
opcfamily => 'spgist/quad_point_ops', opcintype => 'point' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'kd_point_ops',
|
|
|
|
opcfamily => 'spgist/kd_point_ops', opcintype => 'point', opcdefault => 'f' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'text_ops', opcfamily => 'spgist/text_ops',
|
|
|
|
opcintype => 'text' },
|
|
|
|
{ opcmethod => 'spgist', opcname => 'poly_ops', opcfamily => 'spgist/poly_ops',
|
|
|
|
opcintype => 'polygon', opckeytype => 'box' },
|
|
|
|
{ opcmethod => 'btree', opcname => 'jsonb_ops', opcfamily => 'btree/jsonb_ops',
|
|
|
|
opcintype => 'jsonb' },
|
|
|
|
{ opcmethod => 'hash', opcname => 'jsonb_ops', opcfamily => 'hash/jsonb_ops',
|
|
|
|
opcintype => 'jsonb' },
|
|
|
|
{ opcmethod => 'gin', opcname => 'jsonb_ops', opcfamily => 'gin/jsonb_ops',
|
|
|
|
opcintype => 'jsonb', opckeytype => 'text' },
|
|
|
|
{ opcmethod => 'gin', opcname => 'jsonb_path_ops',
|
|
|
|
opcfamily => 'gin/jsonb_path_ops', opcintype => 'jsonb', opcdefault => 'f',
|
|
|
|
opckeytype => 'int4' },
|
|
|
|
|
|
|
|
# BRIN operator classes
|
|
|
|
|
|
|
|
# no brin opclass for bool
|
|
|
|
|
|
|
|
{ opcmethod => 'brin', opcname => 'bytea_minmax_ops',
|
|
|
|
opcfamily => 'brin/bytea_minmax_ops', opcintype => 'bytea',
|
|
|
|
opckeytype => 'bytea' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'char_minmax_ops',
|
|
|
|
opcfamily => 'brin/char_minmax_ops', opcintype => 'char',
|
|
|
|
opckeytype => 'char' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'name_minmax_ops',
|
|
|
|
opcfamily => 'brin/name_minmax_ops', opcintype => 'name',
|
|
|
|
opckeytype => 'name' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'int8_minmax_ops',
|
|
|
|
opcfamily => 'brin/integer_minmax_ops', opcintype => 'int8',
|
|
|
|
opckeytype => 'int8' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'int2_minmax_ops',
|
|
|
|
opcfamily => 'brin/integer_minmax_ops', opcintype => 'int2',
|
|
|
|
opckeytype => 'int2' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'int4_minmax_ops',
|
|
|
|
opcfamily => 'brin/integer_minmax_ops', opcintype => 'int4',
|
|
|
|
opckeytype => 'int4' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'text_minmax_ops',
|
|
|
|
opcfamily => 'brin/text_minmax_ops', opcintype => 'text',
|
|
|
|
opckeytype => 'text' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'oid_minmax_ops',
|
|
|
|
opcfamily => 'brin/oid_minmax_ops', opcintype => 'oid', opckeytype => 'oid' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'tid_minmax_ops',
|
|
|
|
opcfamily => 'brin/tid_minmax_ops', opcintype => 'tid', opckeytype => 'tid' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'float4_minmax_ops',
|
|
|
|
opcfamily => 'brin/float_minmax_ops', opcintype => 'float4',
|
|
|
|
opckeytype => 'float4' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'float8_minmax_ops',
|
|
|
|
opcfamily => 'brin/float_minmax_ops', opcintype => 'float8',
|
|
|
|
opckeytype => 'float8' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'macaddr_minmax_ops',
|
|
|
|
opcfamily => 'brin/macaddr_minmax_ops', opcintype => 'macaddr',
|
|
|
|
opckeytype => 'macaddr' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'macaddr8_minmax_ops',
|
|
|
|
opcfamily => 'brin/macaddr8_minmax_ops', opcintype => 'macaddr8',
|
|
|
|
opckeytype => 'macaddr8' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'inet_minmax_ops',
|
|
|
|
opcfamily => 'brin/network_minmax_ops', opcintype => 'inet',
|
|
|
|
opcdefault => 'f', opckeytype => 'inet' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'inet_inclusion_ops',
|
|
|
|
opcfamily => 'brin/network_inclusion_ops', opcintype => 'inet',
|
|
|
|
opckeytype => 'inet' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'bpchar_minmax_ops',
|
|
|
|
opcfamily => 'brin/bpchar_minmax_ops', opcintype => 'bpchar',
|
|
|
|
opckeytype => 'bpchar' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'time_minmax_ops',
|
|
|
|
opcfamily => 'brin/time_minmax_ops', opcintype => 'time',
|
|
|
|
opckeytype => 'time' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'date_minmax_ops',
|
|
|
|
opcfamily => 'brin/datetime_minmax_ops', opcintype => 'date',
|
|
|
|
opckeytype => 'date' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'timestamp_minmax_ops',
|
|
|
|
opcfamily => 'brin/datetime_minmax_ops', opcintype => 'timestamp',
|
|
|
|
opckeytype => 'timestamp' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'timestamptz_minmax_ops',
|
|
|
|
opcfamily => 'brin/datetime_minmax_ops', opcintype => 'timestamptz',
|
|
|
|
opckeytype => 'timestamptz' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'interval_minmax_ops',
|
|
|
|
opcfamily => 'brin/interval_minmax_ops', opcintype => 'interval',
|
|
|
|
opckeytype => 'interval' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'timetz_minmax_ops',
|
|
|
|
opcfamily => 'brin/timetz_minmax_ops', opcintype => 'timetz',
|
|
|
|
opckeytype => 'timetz' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'bit_minmax_ops',
|
|
|
|
opcfamily => 'brin/bit_minmax_ops', opcintype => 'bit', opckeytype => 'bit' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'varbit_minmax_ops',
|
|
|
|
opcfamily => 'brin/varbit_minmax_ops', opcintype => 'varbit',
|
|
|
|
opckeytype => 'varbit' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'numeric_minmax_ops',
|
|
|
|
opcfamily => 'brin/numeric_minmax_ops', opcintype => 'numeric',
|
|
|
|
opckeytype => 'numeric' },
|
|
|
|
|
|
|
|
# no brin opclass for record, anyarray
|
|
|
|
|
|
|
|
{ opcmethod => 'brin', opcname => 'uuid_minmax_ops',
|
|
|
|
opcfamily => 'brin/uuid_minmax_ops', opcintype => 'uuid',
|
|
|
|
opckeytype => 'uuid' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'range_inclusion_ops',
|
|
|
|
opcfamily => 'brin/range_inclusion_ops', opcintype => 'anyrange',
|
|
|
|
opckeytype => 'anyrange' },
|
|
|
|
{ opcmethod => 'brin', opcname => 'pg_lsn_minmax_ops',
|
|
|
|
opcfamily => 'brin/pg_lsn_minmax_ops', opcintype => 'pg_lsn',
|
|
|
|
opckeytype => 'pg_lsn' },
|
|
|
|
|
|
|
|
# no brin opclass for enum, tsvector, tsquery, jsonb
|
|
|
|
|
|
|
|
{ opcmethod => 'brin', opcname => 'box_inclusion_ops',
|
|
|
|
opcfamily => 'brin/box_inclusion_ops', opcintype => 'box',
|
|
|
|
opckeytype => 'box' },
|
|
|
|
|
|
|
|
# no brin opclass for the geometric types except box
|
|
|
|
|
|
|
|
]
|