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_amop.dat
|
2018-04-19 23:14:09 +02:00
|
|
|
# Initial contents of the pg_amop 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
|
|
|
#
|
2022-01-08 01:04:57 +01:00
|
|
|
# Portions Copyright (c) 1996-2022, 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_amop.dat
|
|
|
|
#
|
|
|
|
#----------------------------------------------------------------------
|
|
|
|
|
|
|
|
[
|
|
|
|
|
|
|
|
# btree integer_ops
|
|
|
|
|
|
|
|
# default operators int2
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int24
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int28
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# default operators int4
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int42
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int48
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# default operators int8
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int82
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators int84
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree oid_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '1', amopopr => '<(oid,oid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '2', amopopr => '<=(oid,oid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '3', amopopr => '=(oid,oid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '4', amopopr => '>=(oid,oid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '5', amopopr => '>(oid,oid)', amopmethod => 'btree' },
|
|
|
|
|
2020-04-07 01:08:14 +02:00
|
|
|
# btree xid8_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '1', amopopr => '<(xid8,xid8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '2', amopopr => '<=(xid8,xid8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '3', amopopr => '=(xid8,xid8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '4', amopopr => '>=(xid8,xid8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '5', amopopr => '>(xid8,xid8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
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
|
|
|
# btree tid_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '1', amopopr => '<(tid,tid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '2', amopopr => '<=(tid,tid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '3', amopopr => '=(tid,tid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '4', amopopr => '>=(tid,tid)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '5', amopopr => '>(tid,tid)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree oidvector_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '1',
|
|
|
|
amopopr => '<(oidvector,oidvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '2',
|
|
|
|
amopopr => '<=(oidvector,oidvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '3',
|
|
|
|
amopopr => '=(oidvector,oidvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '4',
|
|
|
|
amopopr => '>=(oidvector,oidvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '5',
|
|
|
|
amopopr => '>(oidvector,oidvector)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree float_ops
|
|
|
|
|
|
|
|
# default operators float4
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float4,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float4)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float4,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float4)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float4,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators float48
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float4,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float4,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float4,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# default operators float8
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float8,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float8,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float8,float8)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators float84
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float8,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float4)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float8,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float4)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float8,float4)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree char_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '1', amopopr => '<(char,char)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '2', amopopr => '<=(char,char)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '3', amopopr => '=(char,char)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '4', amopopr => '>=(char,char)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '5', amopopr => '>(char,char)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
2018-12-19 23:46:07 +01:00
|
|
|
# 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
|
|
|
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '<(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '2', amopopr => '<=(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '4', amopopr => '>=(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '5', amopopr => '>(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
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
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '<(name,name)',
|
|
|
|
amopmethod => 'btree' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
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
|
|
|
amoprighttype => 'name', amopstrategy => '2', amopopr => '<=(name,name)',
|
|
|
|
amopmethod => 'btree' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
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
|
|
|
amoprighttype => 'name', amopstrategy => '3', amopopr => '=(name,name)',
|
|
|
|
amopmethod => 'btree' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
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
|
|
|
amoprighttype => 'name', amopstrategy => '4', amopopr => '>=(name,name)',
|
|
|
|
amopmethod => 'btree' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
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
|
|
|
amoprighttype => 'name', amopstrategy => '5', amopopr => '>(name,name)',
|
|
|
|
amopmethod => 'btree' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '<(name,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '2', amopopr => '<=(name,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(name,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '4', amopopr => '>=(name,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '5', amopopr => '>(name,text)',
|
|
|
|
amopmethod => 'btree' },
|
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
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
2018-12-19 23:46:07 +01:00
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '<(text,name)',
|
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
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
2018-12-19 23:46:07 +01:00
|
|
|
amoprighttype => 'name', amopstrategy => '2', amopopr => '<=(text,name)',
|
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
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
2018-12-19 23:46:07 +01:00
|
|
|
amoprighttype => 'name', amopstrategy => '3', amopopr => '=(text,name)',
|
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
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
2018-12-19 23:46:07 +01:00
|
|
|
amoprighttype => 'name', amopstrategy => '4', amopopr => '>=(text,name)',
|
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
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_ops', amoplefttype => 'text',
|
2018-12-19 23:46:07 +01:00
|
|
|
amoprighttype => 'name', amopstrategy => '5', amopopr => '>(text,name)',
|
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
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree bpchar_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '<(bpchar,bpchar)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '2',
|
|
|
|
amopopr => '<=(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '3', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '4',
|
|
|
|
amopopr => '>=(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '5', amopopr => '>(bpchar,bpchar)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree bytea_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '1', amopopr => '<(bytea,bytea)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '2', amopopr => '<=(bytea,bytea)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '3', amopopr => '=(bytea,bytea)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '4', amopopr => '>=(bytea,bytea)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '5', amopopr => '>(bytea,bytea)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree datetime_ops
|
|
|
|
|
|
|
|
# default operators date
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(date,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(date,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(date,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(date,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(date,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs timestamp
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamp)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs timestamptz
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamptz)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# default operators timestamp
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamp)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs date
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(timestamp,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(timestamp,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(timestamp,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(timestamp,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(timestamp,date)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs timestamptz
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamptz)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# default operators timestamptz
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamptz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamptz)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs date
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,date)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,date)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,date)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,date)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,date)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# crosstype operators vs timestamp
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamp)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/datetime_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamp)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree time_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '1', amopopr => '<(time,time)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '2', amopopr => '<=(time,time)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '3', amopopr => '=(time,time)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '4', amopopr => '>=(time,time)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '5', amopopr => '>(time,time)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree timetz_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '<(timetz,timetz)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timetz,timetz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '3', amopopr => '=(timetz,timetz)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timetz,timetz)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '5', amopopr => '>(timetz,timetz)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree interval_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '1',
|
|
|
|
amopopr => '<(interval,interval)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '2',
|
|
|
|
amopopr => '<=(interval,interval)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '3',
|
|
|
|
amopopr => '=(interval,interval)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '4',
|
|
|
|
amopopr => '>=(interval,interval)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '5',
|
|
|
|
amopopr => '>(interval,interval)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree macaddr
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr,macaddr)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr,macaddr)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr,macaddr)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr,macaddr)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr,macaddr)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree macaddr8
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr8,macaddr8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr8,macaddr8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr8,macaddr8)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr8,macaddr8)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree network
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '1', amopopr => '<(inet,inet)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '2', amopopr => '<=(inet,inet)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '4', amopopr => '>=(inet,inet)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '5', amopopr => '>(inet,inet)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree numeric
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '1',
|
|
|
|
amopopr => '<(numeric,numeric)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '2',
|
|
|
|
amopopr => '<=(numeric,numeric)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '3',
|
|
|
|
amopopr => '=(numeric,numeric)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '4',
|
|
|
|
amopopr => '>=(numeric,numeric)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '5',
|
|
|
|
amopopr => '>(numeric,numeric)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree bool
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '1', amopopr => '<(bool,bool)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '2', amopopr => '<=(bool,bool)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '3', amopopr => '=(bool,bool)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '4', amopopr => '>=(bool,bool)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '5', amopopr => '>(bool,bool)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree bit
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/bit_ops', amoplefttype => 'bit', amoprighttype => 'bit',
|
|
|
|
amopstrategy => '1', amopopr => '<(bit,bit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bit_ops', amoplefttype => 'bit', amoprighttype => 'bit',
|
|
|
|
amopstrategy => '2', amopopr => '<=(bit,bit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bit_ops', amoplefttype => 'bit', amoprighttype => 'bit',
|
|
|
|
amopstrategy => '3', amopopr => '=(bit,bit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bit_ops', amoplefttype => 'bit', amoprighttype => 'bit',
|
|
|
|
amopstrategy => '4', amopopr => '>=(bit,bit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bit_ops', amoplefttype => 'bit', amoprighttype => 'bit',
|
|
|
|
amopstrategy => '5', amopopr => '>(bit,bit)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree varbit
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/varbit_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '1', amopopr => '<(varbit,varbit)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/varbit_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '2',
|
|
|
|
amopopr => '<=(varbit,varbit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/varbit_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '3', amopopr => '=(varbit,varbit)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/varbit_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '4',
|
|
|
|
amopopr => '>=(varbit,varbit)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/varbit_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '5', amopopr => '>(varbit,varbit)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree text pattern
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '~<~(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '2', amopopr => '~<=~(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '4', amopopr => '~>=~(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '5', amopopr => '~>~(text,text)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree bpchar pattern
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1',
|
|
|
|
amopopr => '~<~(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '2',
|
|
|
|
amopopr => '~<=~(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '3', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '4',
|
|
|
|
amopopr => '~>=~(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '5',
|
|
|
|
amopopr => '~>~(bpchar,bpchar)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree money_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/money_ops', amoplefttype => 'money',
|
|
|
|
amoprighttype => 'money', amopstrategy => '1', amopopr => '<(money,money)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/money_ops', amoplefttype => 'money',
|
|
|
|
amoprighttype => 'money', amopstrategy => '2', amopopr => '<=(money,money)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/money_ops', amoplefttype => 'money',
|
|
|
|
amoprighttype => 'money', amopstrategy => '3', amopopr => '=(money,money)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/money_ops', amoplefttype => 'money',
|
|
|
|
amoprighttype => 'money', amopstrategy => '4', amopopr => '>=(money,money)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/money_ops', amoplefttype => 'money',
|
|
|
|
amoprighttype => 'money', amopstrategy => '5', amopopr => '>(money,money)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree array_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '1',
|
|
|
|
amopopr => '<(anyarray,anyarray)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '2',
|
|
|
|
amopopr => '<=(anyarray,anyarray)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '3',
|
|
|
|
amopopr => '=(anyarray,anyarray)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '4',
|
|
|
|
amopopr => '>=(anyarray,anyarray)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '5',
|
|
|
|
amopopr => '>(anyarray,anyarray)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree record_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '1', amopopr => '<(record,record)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '2',
|
|
|
|
amopopr => '<=(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '3', amopopr => '=(record,record)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '4',
|
|
|
|
amopopr => '>=(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '5', amopopr => '>(record,record)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree record_image_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/record_image_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '1',
|
|
|
|
amopopr => '*<(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_image_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '2',
|
|
|
|
amopopr => '*<=(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_image_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '3',
|
|
|
|
amopopr => '*=(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_image_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '4',
|
|
|
|
amopopr => '*>=(record,record)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/record_image_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '5',
|
|
|
|
amopopr => '*>(record,record)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree uuid_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '<(uuid,uuid)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '2', amopopr => '<=(uuid,uuid)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '3', amopopr => '=(uuid,uuid)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '4', amopopr => '>=(uuid,uuid)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '5', amopopr => '>(uuid,uuid)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# btree pg_lsn_ops
|
|
|
|
|
|
|
|
{ amopfamily => 'btree/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '<(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '2',
|
|
|
|
amopopr => '<=(pg_lsn,pg_lsn)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '3', amopopr => '=(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '4',
|
|
|
|
amopopr => '>=(pg_lsn,pg_lsn)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '5', amopopr => '>(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# hash index_ops
|
|
|
|
|
|
|
|
# bpchar_ops
|
|
|
|
{ amopfamily => 'hash/bpchar_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# char_ops
|
|
|
|
{ amopfamily => 'hash/char_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '1', amopopr => '=(char,char)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# date_ops
|
|
|
|
{ amopfamily => 'hash/date_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '=(date,date)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# float_ops
|
|
|
|
{ amopfamily => 'hash/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '=(float4,float4)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '=(float8,float8)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/float_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '=(float4,float8)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/float_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '=(float8,float4)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# network_ops
|
|
|
|
{ amopfamily => 'hash/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '1', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# integer_ops
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '=(int2,int2)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '=(int4,int4)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '=(int8,int8)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '=(int2,int4)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '=(int2,int8)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '=(int4,int2)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '=(int4,int8)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '=(int8,int2)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/integer_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '=(int8,int4)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# interval_ops
|
|
|
|
{ amopfamily => 'hash/interval_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '1',
|
|
|
|
amopopr => '=(interval,interval)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# macaddr_ops
|
|
|
|
{ amopfamily => 'hash/macaddr_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '1',
|
|
|
|
amopopr => '=(macaddr,macaddr)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# macaddr8_ops
|
|
|
|
{ amopfamily => 'hash/macaddr8_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '1',
|
|
|
|
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# oid_ops
|
|
|
|
{ amopfamily => 'hash/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
|
|
|
|
amopstrategy => '1', amopopr => '=(oid,oid)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# oidvector_ops
|
|
|
|
{ amopfamily => 'hash/oidvector_ops', amoplefttype => 'oidvector',
|
|
|
|
amoprighttype => 'oidvector', amopstrategy => '1',
|
|
|
|
amopopr => '=(oidvector,oidvector)', amopmethod => 'hash' },
|
|
|
|
|
2020-11-19 09:24:37 +01:00
|
|
|
# record_ops
|
|
|
|
{ amopfamily => 'hash/record_ops', amoplefttype => 'record',
|
|
|
|
amoprighttype => 'record', amopstrategy => '1', amopopr => '=(record,record)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
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
|
|
|
# text_ops
|
|
|
|
{ amopfamily => 'hash/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'hash' },
|
2018-12-19 23:46:07 +01:00
|
|
|
{ amopfamily => 'hash/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '=(name,name)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/text_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(name,text)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
{ amopfamily => 'hash/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '=(text,name)',
|
|
|
|
amopmethod => 'hash' },
|
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
|
|
|
|
|
|
|
# time_ops
|
|
|
|
{ amopfamily => 'hash/time_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '1', amopopr => '=(time,time)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# timestamptz_ops
|
|
|
|
{ amopfamily => 'hash/timestamptz_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# timetz_ops
|
|
|
|
{ amopfamily => 'hash/timetz_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '=(timetz,timetz)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# timestamp_ops
|
|
|
|
{ amopfamily => 'hash/timestamp_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '=(timestamp,timestamp)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# bool_ops
|
|
|
|
{ amopfamily => 'hash/bool_ops', amoplefttype => 'bool',
|
|
|
|
amoprighttype => 'bool', amopstrategy => '1', amopopr => '=(bool,bool)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# bytea_ops
|
|
|
|
{ amopfamily => 'hash/bytea_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '1', amopopr => '=(bytea,bytea)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# xid_ops
|
|
|
|
{ amopfamily => 'hash/xid_ops', amoplefttype => 'xid', amoprighttype => 'xid',
|
|
|
|
amopstrategy => '1', amopopr => '=(xid,xid)', amopmethod => 'hash' },
|
|
|
|
|
2020-04-07 01:08:14 +02:00
|
|
|
# xid8_ops
|
2020-05-12 19:03:43 +02:00
|
|
|
{ amopfamily => 'hash/xid8_ops', amoplefttype => 'xid8',
|
|
|
|
amoprighttype => 'xid8', amopstrategy => '1', amopopr => '=(xid8,xid8)',
|
|
|
|
amopmethod => 'hash' },
|
2020-04-07 01:08:14 +02:00
|
|
|
|
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
|
|
|
# cid_ops
|
|
|
|
{ amopfamily => 'hash/cid_ops', amoplefttype => 'cid', amoprighttype => 'cid',
|
|
|
|
amopstrategy => '1', amopopr => '=(cid,cid)', amopmethod => 'hash' },
|
|
|
|
|
2018-12-30 21:40:04 +01:00
|
|
|
# tid_ops
|
|
|
|
{ amopfamily => 'hash/tid_ops', amoplefttype => 'tid', amoprighttype => 'tid',
|
|
|
|
amopstrategy => '1', amopopr => '=(tid,tid)', amopmethod => 'hash' },
|
|
|
|
|
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
|
|
|
# text_pattern_ops
|
|
|
|
{ amopfamily => 'hash/text_pattern_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# bpchar_pattern_ops
|
|
|
|
{ amopfamily => 'hash/bpchar_pattern_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# aclitem_ops
|
|
|
|
{ amopfamily => 'hash/aclitem_ops', amoplefttype => 'aclitem',
|
|
|
|
amoprighttype => 'aclitem', amopstrategy => '1',
|
|
|
|
amopopr => '=(aclitem,aclitem)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# uuid_ops
|
|
|
|
{ amopfamily => 'hash/uuid_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '=(uuid,uuid)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# pg_lsn_ops
|
|
|
|
{ amopfamily => 'hash/pg_lsn_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '=(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# numeric_ops
|
|
|
|
{ amopfamily => 'hash/numeric_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '1',
|
|
|
|
amopopr => '=(numeric,numeric)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# array_ops
|
|
|
|
{ amopfamily => 'hash/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '1',
|
|
|
|
amopopr => '=(anyarray,anyarray)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# gist box_ops
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '1', amopopr => '<<(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '2', amopopr => '&<(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '3', amopopr => '&&(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '4', amopopr => '&>(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '5', amopopr => '>>(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '6', amopopr => '~=(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '7', amopopr => '@>(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '8', amopopr => '<@(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '9', amopopr => '&<|(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '10', amopopr => '<<|(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '11', amopopr => '|>>(box,box)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '12', amopopr => '|&>(box,box)', amopmethod => 'gist' },
|
2019-07-14 13:56:18 +02:00
|
|
|
{ amopfamily => 'gist/box_ops', amoplefttype => 'box', amoprighttype => 'point',
|
|
|
|
amopstrategy => '15', amoppurpose => 'o', amopopr => '<->(box,point)',
|
|
|
|
amopmethod => 'gist', amopsortfamily => 'btree/float_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
|
|
|
|
|
|
|
# gist point_ops
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
|
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
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
|
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
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(point,point)', amopmethod => 'gist',
|
|
|
|
amopsortfamily => 'btree/float_ops' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'box', amopstrategy => '28', amopopr => '<@(point,box)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '48',
|
|
|
|
amopopr => '<@(point,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '68',
|
|
|
|
amopopr => '<@(point,circle)', amopmethod => 'gist' },
|
|
|
|
|
|
|
|
# gist poly_ops (supports polygons)
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '1',
|
|
|
|
amopopr => '<<(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '2',
|
|
|
|
amopopr => '&<(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '3',
|
|
|
|
amopopr => '&&(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '4',
|
|
|
|
amopopr => '&>(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '5',
|
|
|
|
amopopr => '>>(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '6',
|
|
|
|
amopopr => '~=(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '7',
|
|
|
|
amopopr => '@>(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '8',
|
|
|
|
amopopr => '<@(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '9',
|
|
|
|
amopopr => '&<|(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '10',
|
|
|
|
amopopr => '<<|(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '11',
|
|
|
|
amopopr => '|>>(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '12',
|
|
|
|
amopopr => '|&>(polygon,polygon)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(polygon,point)', amopmethod => 'gist',
|
|
|
|
amopsortfamily => 'btree/float_ops' },
|
|
|
|
|
|
|
|
# gist circle_ops
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '1',
|
|
|
|
amopopr => '<<(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '2',
|
|
|
|
amopopr => '&<(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '3',
|
|
|
|
amopopr => '&&(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '4',
|
|
|
|
amopopr => '&>(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '5',
|
|
|
|
amopopr => '>>(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '6',
|
|
|
|
amopopr => '~=(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '7',
|
|
|
|
amopopr => '@>(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '8',
|
|
|
|
amopopr => '<@(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '9',
|
|
|
|
amopopr => '&<|(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '10',
|
|
|
|
amopopr => '<<|(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '11',
|
|
|
|
amopopr => '|>>(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'circle', amopstrategy => '12',
|
|
|
|
amopopr => '|&>(circle,circle)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
|
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(circle,point)', amopmethod => 'gist',
|
|
|
|
amopsortfamily => 'btree/float_ops' },
|
|
|
|
|
|
|
|
# gin array_ops
|
|
|
|
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '1',
|
|
|
|
amopopr => '&&(anyarray,anyarray)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '2',
|
|
|
|
amopopr => '@>(anyarray,anyarray)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '3',
|
|
|
|
amopopr => '<@(anyarray,anyarray)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
|
|
|
|
amoprighttype => 'anyarray', amopstrategy => '4',
|
|
|
|
amopopr => '=(anyarray,anyarray)', amopmethod => 'gin' },
|
|
|
|
|
|
|
|
# btree enum_ops
|
|
|
|
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '1',
|
|
|
|
amopopr => '<(anyenum,anyenum)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '2',
|
|
|
|
amopopr => '<=(anyenum,anyenum)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '3',
|
|
|
|
amopopr => '=(anyenum,anyenum)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '4',
|
|
|
|
amopopr => '>=(anyenum,anyenum)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '5',
|
|
|
|
amopopr => '>(anyenum,anyenum)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# hash enum_ops
|
|
|
|
{ amopfamily => 'hash/enum_ops', amoplefttype => 'anyenum',
|
|
|
|
amoprighttype => 'anyenum', amopstrategy => '1',
|
|
|
|
amopopr => '=(anyenum,anyenum)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# btree tsvector_ops
|
|
|
|
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsvector', amopstrategy => '1',
|
|
|
|
amopopr => '<(tsvector,tsvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsvector', amopstrategy => '2',
|
|
|
|
amopopr => '<=(tsvector,tsvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsvector', amopstrategy => '3',
|
|
|
|
amopopr => '=(tsvector,tsvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsvector', amopstrategy => '4',
|
|
|
|
amopopr => '>=(tsvector,tsvector)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsvector', amopstrategy => '5',
|
|
|
|
amopopr => '>(tsvector,tsvector)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# GiST tsvector_ops
|
|
|
|
{ amopfamily => 'gist/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '1',
|
|
|
|
amopopr => '@@(tsvector,tsquery)', amopmethod => 'gist' },
|
|
|
|
|
|
|
|
# GIN tsvector_ops
|
|
|
|
{ amopfamily => 'gin/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '1',
|
|
|
|
amopopr => '@@(tsvector,tsquery)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/tsvector_ops', amoplefttype => 'tsvector',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '2',
|
|
|
|
amopopr => '@@@(tsvector,tsquery)', amopmethod => 'gin' },
|
|
|
|
|
|
|
|
# btree tsquery_ops
|
|
|
|
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '1',
|
|
|
|
amopopr => '<(tsquery,tsquery)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '2',
|
|
|
|
amopopr => '<=(tsquery,tsquery)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '3',
|
|
|
|
amopopr => '=(tsquery,tsquery)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '4',
|
|
|
|
amopopr => '>=(tsquery,tsquery)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '5',
|
|
|
|
amopopr => '>(tsquery,tsquery)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# GiST tsquery_ops
|
|
|
|
{ amopfamily => 'gist/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '7',
|
|
|
|
amopopr => '@>(tsquery,tsquery)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/tsquery_ops', amoplefttype => 'tsquery',
|
|
|
|
amoprighttype => 'tsquery', amopstrategy => '8',
|
|
|
|
amopopr => '<@(tsquery,tsquery)', amopmethod => 'gist' },
|
|
|
|
|
|
|
|
# btree range_ops
|
|
|
|
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '<(anyrange,anyrange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '2',
|
|
|
|
amopopr => '<=(anyrange,anyrange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '3',
|
|
|
|
amopopr => '=(anyrange,anyrange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '4',
|
|
|
|
amopopr => '>=(anyrange,anyrange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '5',
|
|
|
|
amopopr => '>(anyrange,anyrange)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# hash range_ops
|
|
|
|
{ amopfamily => 'hash/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '=(anyrange,anyrange)', amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# GiST range_ops
|
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '6',
|
|
|
|
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '6',
|
|
|
|
amopopr => '-|-(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anyrange,anyrange)', amopmethod => 'gist' },
|
2020-12-29 21:36:43 +01:00
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anyrange,anymultirange)', amopmethod => 'gist' },
|
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
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyelement', amopstrategy => '16',
|
|
|
|
amopopr => '@>(anyrange,anyelement)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '18',
|
|
|
|
amopopr => '=(anyrange,anyrange)', amopmethod => 'gist' },
|
|
|
|
|
2020-12-29 21:36:43 +01:00
|
|
|
# GiST multirange_ops
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '6',
|
|
|
|
amopopr => '-|-(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '6',
|
|
|
|
amopopr => '-|-(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anymultirange,anyrange)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anyelement', amopstrategy => '16',
|
|
|
|
amopopr => '@>(anymultirange,anyelement)', amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '18',
|
|
|
|
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'gist' },
|
|
|
|
|
Multirange datatypes
Multiranges are basically sorted arrays of non-overlapping ranges with
set-theoretic operations defined over them.
Since v14, each range type automatically gets a corresponding multirange
datatype. There are both manual and automatic mechanisms for naming multirange
types. Once can specify multirange type name using multirange_type_name
attribute in CREATE TYPE. Otherwise, a multirange type name is generated
automatically. If the range type name contains "range" then we change that to
"multirange". Otherwise, we add "_multirange" to the end.
Implementation of multiranges comes with a space-efficient internal
representation format, which evades extra paddings and duplicated storage of
oids. Altogether this format allows fetching a particular range by its index
in O(n).
Statistic gathering and selectivity estimation are implemented for multiranges.
For this purpose, stored multirange is approximated as union range without gaps.
This field will likely need improvements in the future.
Catversion is bumped.
Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com
Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0
Author: Paul Jungwirth, revised by me
Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule
Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston
Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
|
|
|
# btree multirange_ops
|
|
|
|
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '1',
|
|
|
|
amopopr => '<(anymultirange,anymultirange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '2',
|
|
|
|
amopopr => '<=(anymultirange,anymultirange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '3',
|
|
|
|
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '4',
|
|
|
|
amopopr => '>=(anymultirange,anymultirange)', amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '5',
|
|
|
|
amopopr => '>(anymultirange,anymultirange)', amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# hash multirange_ops
|
|
|
|
{ amopfamily => 'hash/multirange_ops', amoplefttype => 'anymultirange',
|
|
|
|
amoprighttype => 'anymultirange', amopstrategy => '1',
|
|
|
|
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'hash' },
|
|
|
|
|
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
|
|
|
# SP-GiST quad_point_ops
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
|
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
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
|
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
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(point,box)',
|
|
|
|
amopmethod => 'spgist' },
|
2018-09-19 00:54:10 +02:00
|
|
|
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
|
2018-09-20 22:06:18 +02:00
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(point,point)', amopmethod => 'spgist',
|
2018-09-19 00:54:10 +02:00
|
|
|
amopsortfamily => 'btree/float_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
|
|
|
|
|
|
|
# SP-GiST kd_point_ops
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
|
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
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
2020-11-23 17:38:37 +01:00
|
|
|
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
|
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
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
|
|
|
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(point,box)',
|
|
|
|
amopmethod => 'spgist' },
|
2018-09-19 00:54:10 +02:00
|
|
|
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
|
2018-09-20 22:06:18 +02:00
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(point,point)', amopmethod => 'spgist',
|
2018-09-19 00:54:10 +02:00
|
|
|
amopsortfamily => 'btree/float_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
|
|
|
|
|
|
|
# SP-GiST text_ops
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '~<~(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '2', amopopr => '~<=~(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '4', amopopr => '~>=~(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '5', amopopr => '~>~(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '11', amopopr => '<(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '12', amopopr => '<=(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '14', amopopr => '>=(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '15', amopopr => '>(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/text_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '28', amopopr => '^@(text,text)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
|
|
|
|
# btree jsonb_ops
|
|
|
|
{ amopfamily => 'btree/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '1', amopopr => '<(jsonb,jsonb)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '2', amopopr => '<=(jsonb,jsonb)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '3', amopopr => '=(jsonb,jsonb)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '4', amopopr => '>=(jsonb,jsonb)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
{ amopfamily => 'btree/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '5', amopopr => '>(jsonb,jsonb)',
|
|
|
|
amopmethod => 'btree' },
|
|
|
|
|
|
|
|
# hash jsonb_ops
|
|
|
|
{ amopfamily => 'hash/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '1', amopopr => '=(jsonb,jsonb)',
|
|
|
|
amopmethod => 'hash' },
|
|
|
|
|
|
|
|
# GIN jsonb_ops
|
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '7', amopopr => '@>(jsonb,jsonb)',
|
|
|
|
amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'text', amopstrategy => '9', amopopr => '?(jsonb,text)',
|
|
|
|
amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => '_text', amopstrategy => '10', amopopr => '?|(jsonb,_text)',
|
|
|
|
amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => '_text', amopstrategy => '11', amopopr => '?&(jsonb,_text)',
|
|
|
|
amopmethod => 'gin' },
|
2019-04-01 17:08:15 +02:00
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonpath', amopstrategy => '15',
|
|
|
|
amopopr => '@?(jsonb,jsonpath)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/jsonb_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonpath', amopstrategy => '16',
|
|
|
|
amopopr => '@@(jsonb,jsonpath)', amopmethod => 'gin' },
|
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
|
|
|
|
|
|
|
# GIN jsonb_path_ops
|
|
|
|
{ amopfamily => 'gin/jsonb_path_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonb', amopstrategy => '7', amopopr => '@>(jsonb,jsonb)',
|
|
|
|
amopmethod => 'gin' },
|
2019-04-01 17:08:15 +02:00
|
|
|
{ amopfamily => 'gin/jsonb_path_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonpath', amopstrategy => '15',
|
|
|
|
amopopr => '@?(jsonb,jsonpath)', amopmethod => 'gin' },
|
|
|
|
{ amopfamily => 'gin/jsonb_path_ops', amoplefttype => 'jsonb',
|
|
|
|
amoprighttype => 'jsonpath', amopstrategy => '16',
|
|
|
|
amopopr => '@@(jsonb,jsonpath)', amopmethod => 'gin' },
|
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
|
|
|
|
|
|
|
# SP-GiST range_ops
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '6',
|
|
|
|
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyelement', amopstrategy => '16',
|
|
|
|
amopopr => '@>(anyrange,anyelement)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/range_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '18',
|
|
|
|
amopopr => '=(anyrange,anyrange)', amopmethod => 'spgist' },
|
|
|
|
|
|
|
|
# SP-GiST box_ops
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '1', amopopr => '<<(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '2', amopopr => '&<(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '3', amopopr => '&&(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '4', amopopr => '&>(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '5', amopopr => '>>(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '6', amopopr => '~=(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '7', amopopr => '@>(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '8', amopopr => '<@(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '9', amopopr => '&<|(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '10', amopopr => '<<|(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '11', amopopr => '|>>(box,box)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box', amoprighttype => 'box',
|
|
|
|
amopstrategy => '12', amopopr => '|&>(box,box)', amopmethod => 'spgist' },
|
2019-07-14 13:57:53 +02:00
|
|
|
{ amopfamily => 'spgist/box_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(box,point)', amopmethod => 'spgist',
|
|
|
|
amopsortfamily => 'btree/float_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
|
|
|
|
|
|
|
# SP-GiST poly_ops (supports polygons)
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '1',
|
|
|
|
amopopr => '<<(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '2',
|
|
|
|
amopopr => '&<(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '3',
|
|
|
|
amopopr => '&&(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '4',
|
|
|
|
amopopr => '&>(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '5',
|
|
|
|
amopopr => '>>(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '6',
|
|
|
|
amopopr => '~=(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '7',
|
|
|
|
amopopr => '@>(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '8',
|
|
|
|
amopopr => '<@(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '9',
|
|
|
|
amopopr => '&<|(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '10',
|
|
|
|
amopopr => '<<|(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '11',
|
|
|
|
amopopr => '|>>(polygon,polygon)', amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
|
|
|
amoprighttype => 'polygon', amopstrategy => '12',
|
|
|
|
amopopr => '|&>(polygon,polygon)', amopmethod => 'spgist' },
|
2018-09-19 00:54:10 +02:00
|
|
|
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
|
2018-09-20 22:06:18 +02:00
|
|
|
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
|
|
|
|
amopopr => '<->(polygon,point)', amopmethod => 'spgist',
|
2018-09-19 00:54:10 +02:00
|
|
|
amopsortfamily => 'btree/float_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
|
|
|
|
|
|
|
# GiST inet_ops
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '&&(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '18', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '19', amopopr => '<>(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '20', amopopr => '<(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '21', amopopr => '<=(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '22', amopopr => '>(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '23', amopopr => '>=(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '24', amopopr => '<<(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '25', amopopr => '<<=(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '26', amopopr => '>>(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
{ amopfamily => 'gist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '27', amopopr => '>>=(inet,inet)',
|
|
|
|
amopmethod => 'gist' },
|
|
|
|
|
|
|
|
# SP-GiST inet_ops
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '&&(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '18', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '19', amopopr => '<>(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '20', amopopr => '<(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '21', amopopr => '<=(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '22', amopopr => '>(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '23', amopopr => '>=(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '24', amopopr => '<<(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '25', amopopr => '<<=(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '26', amopopr => '>>(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
{ amopfamily => 'spgist/network_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '27', amopopr => '>>=(inet,inet)',
|
|
|
|
amopmethod => 'spgist' },
|
|
|
|
|
|
|
|
# BRIN opclasses
|
|
|
|
|
|
|
|
# minmax bytea
|
|
|
|
{ amopfamily => 'brin/bytea_minmax_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '1', amopopr => '<(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bytea_minmax_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '2', amopopr => '<=(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bytea_minmax_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '3', amopopr => '=(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bytea_minmax_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '4', amopopr => '>=(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bytea_minmax_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '5', amopopr => '>(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom bytea
|
|
|
|
{ amopfamily => 'brin/bytea_bloom_ops', amoplefttype => 'bytea',
|
|
|
|
amoprighttype => 'bytea', amopstrategy => '1', amopopr => '=(bytea,bytea)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax "char"
|
|
|
|
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '1', amopopr => '<(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '2', amopopr => '<=(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '3', amopopr => '=(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '4', amopopr => '>=(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '5', amopopr => '>(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom "char"
|
|
|
|
{ amopfamily => 'brin/char_bloom_ops', amoplefttype => 'char',
|
|
|
|
amoprighttype => 'char', amopstrategy => '1', amopopr => '=(char,char)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax name
|
|
|
|
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '<(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '2', amopopr => '<=(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '3', amopopr => '=(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '4', amopopr => '>=(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '5', amopopr => '>(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom name
|
|
|
|
{ amopfamily => 'brin/name_bloom_ops', amoplefttype => 'name',
|
|
|
|
amoprighttype => 'name', amopstrategy => '1', amopopr => '=(name,name)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax integer
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi integer
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom integer
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int8',
|
|
|
|
amoprighttype => 'int8', amopstrategy => '1', amopopr => '=(int8,int8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int2',
|
|
|
|
amoprighttype => 'int2', amopstrategy => '1', amopopr => '=(int2,int2)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int4',
|
|
|
|
amoprighttype => 'int4', amopstrategy => '1', amopopr => '=(int4,int4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax text
|
|
|
|
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '<(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '2', amopopr => '<=(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '4', amopopr => '>=(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '5', amopopr => '>(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom text
|
|
|
|
{ amopfamily => 'brin/text_bloom_ops', amoplefttype => 'text',
|
|
|
|
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(text,text)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax oid
|
|
|
|
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '1', amopopr => '<(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '2', amopopr => '<=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '3', amopopr => '=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '4', amopopr => '>=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '5', amopopr => '>(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi oid
|
|
|
|
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '1', amopopr => '<(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '2', amopopr => '<=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '3', amopopr => '=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '4', amopopr => '>=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '5', amopopr => '>(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom oid
|
|
|
|
{ amopfamily => 'brin/oid_bloom_ops', amoplefttype => 'oid',
|
|
|
|
amoprighttype => 'oid', amopstrategy => '1', amopopr => '=(oid,oid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax tid
|
|
|
|
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '1', amopopr => '<(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '2', amopopr => '<=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '3', amopopr => '=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '4', amopopr => '>=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '5', amopopr => '>(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# tid oid
|
|
|
|
{ amopfamily => 'brin/tid_bloom_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '1', amopopr => '=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi tid
|
|
|
|
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '1', amopopr => '<(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '2', amopopr => '<=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '3', amopopr => '=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '4', amopopr => '>=(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
|
|
|
|
amoprighttype => 'tid', amopstrategy => '5', amopopr => '>(tid,tid)',
|
|
|
|
amopmethod => 'brin' },
|
2021-03-26 13:35:29 +01:00
|
|
|
|
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
|
|
|
# minmax float (float4, float8)
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi float (float4, float8)
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float4,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float4,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float4,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float4)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float8,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(float8,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(float8,float8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom float
|
|
|
|
{ amopfamily => 'brin/float_bloom_ops', amoplefttype => 'float4',
|
|
|
|
amoprighttype => 'float4', amopstrategy => '1', amopopr => '=(float4,float4)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/float_bloom_ops', amoplefttype => 'float8',
|
|
|
|
amoprighttype => 'float8', amopstrategy => '1', amopopr => '=(float8,float8)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax macaddr
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi macaddr
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom macaddr
|
|
|
|
{ amopfamily => 'brin/macaddr_bloom_ops', amoplefttype => 'macaddr',
|
|
|
|
amoprighttype => 'macaddr', amopstrategy => '1',
|
|
|
|
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax macaddr8
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi macaddr8
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '1',
|
|
|
|
amopopr => '<(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '2',
|
|
|
|
amopopr => '<=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '3',
|
|
|
|
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '4',
|
|
|
|
amopopr => '>=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '5',
|
|
|
|
amopopr => '>(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom macaddr8
|
|
|
|
{ amopfamily => 'brin/macaddr8_bloom_ops', amoplefttype => 'macaddr8',
|
|
|
|
amoprighttype => 'macaddr8', amopstrategy => '1',
|
|
|
|
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax inet
|
|
|
|
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '1', amopopr => '<(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '2', amopopr => '<=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '4', amopopr => '>=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '5', amopopr => '>(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi inet
|
|
|
|
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '1', amopopr => '<(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '2', amopopr => '<=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '4', amopopr => '>=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '5', amopopr => '>(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom inet
|
|
|
|
{ amopfamily => 'brin/network_bloom_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '1', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# inclusion inet
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '3', amopopr => '&&(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '7', amopopr => '>>=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '8', amopopr => '<<=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '18', amopopr => '=(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '24', amopopr => '>>(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
|
|
|
|
amoprighttype => 'inet', amopstrategy => '26', amopopr => '<<(inet,inet)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
# minmax character
|
|
|
|
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '<(bpchar,bpchar)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '2',
|
|
|
|
amopopr => '<=(bpchar,bpchar)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '3', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '4',
|
|
|
|
amopopr => '>=(bpchar,bpchar)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '5', amopopr => '>(bpchar,bpchar)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom character
|
|
|
|
{ amopfamily => 'brin/bpchar_bloom_ops', amoplefttype => 'bpchar',
|
|
|
|
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '=(bpchar,bpchar)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax time without time zone
|
|
|
|
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '1', amopopr => '<(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '2', amopopr => '<=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '3', amopopr => '=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '4', amopopr => '>=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '5', amopopr => '>(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi time without time zone
|
|
|
|
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '1', amopopr => '<(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '2', amopopr => '<=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '3', amopopr => '=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '4', amopopr => '>=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '5', amopopr => '>(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom time without time zone
|
|
|
|
{ amopfamily => 'brin/time_bloom_ops', amoplefttype => 'time',
|
|
|
|
amoprighttype => 'time', amopstrategy => '1', amopopr => '=(time,time)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax datetime (date, timestamp, timestamptz)
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi datetime (date, timestamp, timestamptz)
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(timestamp,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamp,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(date,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'date', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,date)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '<(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '3',
|
|
|
|
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '5',
|
|
|
|
amopopr => '>(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom datetime (date, timestamp, timestamptz)
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'timestamp',
|
|
|
|
amoprighttype => 'timestamp', amopstrategy => '1',
|
|
|
|
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'date',
|
|
|
|
amoprighttype => 'date', amopstrategy => '1', amopopr => '=(date,date)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'timestamptz',
|
|
|
|
amoprighttype => 'timestamptz', amopstrategy => '1',
|
|
|
|
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax interval
|
|
|
|
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '1',
|
|
|
|
amopopr => '<(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '2',
|
|
|
|
amopopr => '<=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '3',
|
|
|
|
amopopr => '=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '4',
|
|
|
|
amopopr => '>=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '5',
|
|
|
|
amopopr => '>(interval,interval)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi interval
|
|
|
|
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '1',
|
|
|
|
amopopr => '<(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '2',
|
|
|
|
amopopr => '<=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '3',
|
|
|
|
amopopr => '=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '4',
|
|
|
|
amopopr => '>=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '5',
|
|
|
|
amopopr => '>(interval,interval)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom interval
|
|
|
|
{ amopfamily => 'brin/interval_bloom_ops', amoplefttype => 'interval',
|
|
|
|
amoprighttype => 'interval', amopstrategy => '1',
|
|
|
|
amopopr => '=(interval,interval)', amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax time with time zone
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '<(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timetz,timetz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '3', amopopr => '=(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timetz,timetz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '5', amopopr => '>(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi time with time zone
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '<(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '2',
|
|
|
|
amopopr => '<=(timetz,timetz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '3', amopopr => '=(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '4',
|
|
|
|
amopopr => '>=(timetz,timetz)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '5', amopopr => '>(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom time with time zone
|
|
|
|
{ amopfamily => 'brin/timetz_bloom_ops', amoplefttype => 'timetz',
|
|
|
|
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '=(timetz,timetz)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax bit
|
|
|
|
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
|
|
|
|
amoprighttype => 'bit', amopstrategy => '1', amopopr => '<(bit,bit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
|
|
|
|
amoprighttype => 'bit', amopstrategy => '2', amopopr => '<=(bit,bit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
|
|
|
|
amoprighttype => 'bit', amopstrategy => '3', amopopr => '=(bit,bit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
|
|
|
|
amoprighttype => 'bit', amopstrategy => '4', amopopr => '>=(bit,bit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
|
|
|
|
amoprighttype => 'bit', amopstrategy => '5', amopopr => '>(bit,bit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
# minmax bit varying
|
|
|
|
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '1', amopopr => '<(varbit,varbit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '2',
|
|
|
|
amopopr => '<=(varbit,varbit)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '3', amopopr => '=(varbit,varbit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '4',
|
|
|
|
amopopr => '>=(varbit,varbit)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
|
|
|
|
amoprighttype => 'varbit', amopstrategy => '5', amopopr => '>(varbit,varbit)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
# minmax numeric
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '1',
|
|
|
|
amopopr => '<(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '2',
|
|
|
|
amopopr => '<=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '3',
|
|
|
|
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '4',
|
|
|
|
amopopr => '>=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '5',
|
|
|
|
amopopr => '>(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi numeric
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '1',
|
|
|
|
amopopr => '<(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '2',
|
|
|
|
amopopr => '<=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '3',
|
|
|
|
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '4',
|
|
|
|
amopopr => '>=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '5',
|
|
|
|
amopopr => '>(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom numeric
|
|
|
|
{ amopfamily => 'brin/numeric_bloom_ops', amoplefttype => 'numeric',
|
|
|
|
amoprighttype => 'numeric', amopstrategy => '1',
|
|
|
|
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# minmax uuid
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '<(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '2', amopopr => '<=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '3', amopopr => '=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '4', amopopr => '>=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '5', amopopr => '>(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi uuid
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '<(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '2', amopopr => '<=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '3', amopopr => '=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '4', amopopr => '>=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '5', amopopr => '>(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom uuid
|
|
|
|
{ amopfamily => 'brin/uuid_bloom_ops', amoplefttype => 'uuid',
|
|
|
|
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '=(uuid,uuid)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# inclusion range types
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '1',
|
|
|
|
amopopr => '<<(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '2',
|
|
|
|
amopopr => '&<(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '3',
|
|
|
|
amopopr => '&&(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '4',
|
|
|
|
amopopr => '&>(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '5',
|
|
|
|
amopopr => '>>(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '7',
|
|
|
|
amopopr => '@>(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '8',
|
|
|
|
amopopr => '<@(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyelement', amopstrategy => '16',
|
|
|
|
amopopr => '@>(anyrange,anyelement)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '17',
|
|
|
|
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '18',
|
|
|
|
amopopr => '=(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '20',
|
|
|
|
amopopr => '<(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '21',
|
|
|
|
amopopr => '<=(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '22',
|
|
|
|
amopopr => '>(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
|
|
|
|
amoprighttype => 'anyrange', amopstrategy => '23',
|
|
|
|
amopopr => '>=(anyrange,anyrange)', amopmethod => 'brin' },
|
|
|
|
|
|
|
|
# minmax pg_lsn
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '<(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '2',
|
|
|
|
amopopr => '<=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '3', amopopr => '=(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '4',
|
|
|
|
amopopr => '>=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '5', amopopr => '>(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:54:29 +01:00
|
|
|
# minmax multi pg_lsn
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '<(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '2',
|
|
|
|
amopopr => '<=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '3', amopopr => '=(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '4',
|
|
|
|
amopopr => '>=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '5', amopopr => '>(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
2021-03-26 13:35:29 +01:00
|
|
|
# bloom pg_lsn
|
|
|
|
{ amopfamily => 'brin/pg_lsn_bloom_ops', amoplefttype => 'pg_lsn',
|
|
|
|
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '=(pg_lsn,pg_lsn)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
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
|
|
|
# inclusion box
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '1', amopopr => '<<(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '2', amopopr => '&<(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '3', amopopr => '&&(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '4', amopopr => '&>(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '5', amopopr => '>>(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '6', amopopr => '~=(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '7', amopopr => '@>(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '9', amopopr => '&<|(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '10', amopopr => '<<|(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '11', amopopr => '|>>(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'box', amopstrategy => '12', amopopr => '|&>(box,box)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
|
|
|
|
amoprighttype => 'point', amopstrategy => '7', amopopr => '@>(box,point)',
|
|
|
|
amopmethod => 'brin' },
|
|
|
|
|
|
|
|
]
|