rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/include/catalog/pg_amop.dat

2446 lines
123 KiB
Plaintext
Raw Normal View History

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
Improve consistency of comments in system catalog headers. Use the term "system catalog" rather than "system relation" in assorted places where it's clearly referring to a table rather than, say, an index. Use more natural word order in the header boilerplate, improve some of the one-liner catalog descriptions, and fix assorted random deviations from the normal boilerplate. All purely neatnik-ism, but why not. John Naylor, some additional cleanup by me Discussion: https://postgr.es/m/CAJVSVGUeJmFB3h-NJ18P32NPa+kzC165nm7GSoGHfPaN80Wxcw@mail.gmail.com
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
#
Update copyrights for 2020 Backpatch-through: update all files in master, backpatch legal files through 9.4
2020-01-01 18:21:45 +01:00
# Portions Copyright (c) 1996-2020, 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' },
Add SQL type xid8 to expose FullTransactionId to users. Similar to xid, but 64 bits wide. This new type is suitable for use in various system views and administration functions. Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Takao Fujii <btfujiitkp@oss.nttdata.com> Reviewed-by: Yoshikazu Imai <imai.yoshikazu@fujitsu.com> Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com> Discussion: https://postgr.es/m/20190725000636.666m5mad25wfbrri%40alap3.anarazel.de
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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',
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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',
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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',
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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',
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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',
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
# text_ops
{ amopfamily => 'hash/text_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(text,text)',
amopmethod => 'hash' },
Add text-vs-name cross-type operators, and unify name_ops with text_ops. Now that name comparison has effectively the same behavior as text comparison, we might as well merge the name_ops opfamily into text_ops, allowing cross-type comparisons to be processed without forcing a datatype coercion first. We need do little more than add cross-type operators to make the opfamily complete, and fix one or two places in the planner that assumed text_ops was a single-datatype opfamily. I chose to unify hash name_ops into hash text_ops as well, since the types have compatible hashing semantics. This allows marking the new cross-type equality operators as oprcanhash. (Note: this doesn't remove the name_ops opclasses, so there's no breakage of index definitions. Those opclasses are just reparented into the text_ops opfamily.) Discussion: https://postgr.es/m/15938.1544377821@sss.pgh.pa.us
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' },
Add SQL type xid8 to expose FullTransactionId to users. Similar to xid, but 64 bits wide. This new type is suitable for use in various system views and administration functions. Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Takao Fujii <btfujiitkp@oss.nttdata.com> Reviewed-by: Yoshikazu Imai <imai.yoshikazu@fujitsu.com> Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com> Discussion: https://postgr.es/m/20190725000636.666m5mad25wfbrri%40alap3.anarazel.de
2020-04-07 01:08:14 +02:00
# xid8_ops
Do pre-release housekeeping on catalog data. Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks specified by RELEASE_CHANGES. For reference, the command was ./renumber_oids.pl --first-mapped-oid=8000 --target-oid=5032 Also run reformat_dat_file.pl while I'm here. Renumbering recently-added types changed some results in the opr_sanity test. To make those a bit easier to eyeball-verify, change the queries to show regtype not just bare type OIDs. (I think we didn't have regtype when these queries were written.)
2020-05-12 19:03:43 +02:00
{ amopfamily => 'hash/xid8_ops', amoplefttype => 'xid8',
amoprighttype => 'xid8', amopstrategy => '1', amopopr => '=(xid8,xid8)',
amopmethod => 'hash' },
Add SQL type xid8 to expose FullTransactionId to users. Similar to xid, but 64 bits wide. This new type is suitable for use in various system views and administration functions. Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com> Reviewed-by: Takao Fujii <btfujiitkp@oss.nttdata.com> Reviewed-by: Yoshikazu Imai <imai.yoshikazu@fujitsu.com> Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com> Discussion: https://postgr.es/m/20190725000636.666m5mad25wfbrri%40alap3.anarazel.de
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' },
Add a hash opclass for type "tid". Up to now we've not worried much about joins where the join key is a relation's CTID column, reasoning that storing a table's CTIDs in some other table would be pretty useless. However, there are use-cases for this sort of query involving self-joins, so that argument doesn't really hold water. With larger relations, a merge or hash join is desirable. We had a btree opclass for type "tid", allowing merge joins on CTID, but no hash opclass so that hash joins weren't possible. Add the missing infrastructure. This also potentially enables hash aggregation on "tid", though the use-cases for that aren't too clear. Discussion: https://postgr.es/m/1853.1545453106@sss.pgh.pa.us
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' },
Add support for <-> (box, point) operator to GiST box_ops Index-based calculation of this operator is exact. So, signature of gist_bbox_distance() function is changes so that caller is responsible for setting *recheck flag. Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru Author: Nikita Glukhov Reviewed-by: Tom Lane, Alexander Korotkov
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',
amoprighttype => 'point', amopstrategy => '11', amopopr => '>^(point,point)',
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',
amoprighttype => 'point', amopstrategy => '10', amopopr => '<^(point,point)',
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' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '2',
amopopr => '&<(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '3',
amopopr => '&&(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '4',
amopopr => '&>(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '5',
amopopr => '>>(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '6',
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '7',
amopopr => '@>(anyrange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '8',
amopopr => '<@(anyrange,anyrange)', amopmethod => 'gist' },
{ 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' },
# SP-GiST quad_point_ops
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '11', amopopr => '>^(point,point)',
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',
amoprighttype => 'point', amopstrategy => '10', amopopr => '<^(point,point)',
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' },
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
2018-09-19 00:54:10 +02:00
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
Add missing pg_description strings for pg_type entries. I noticed that all non-composite, non-array entries in pg_type.dat had descr strings, except for "json" and the pseudo-types. The lack for json seems certainly an oversight, and there's surely little reason to not have entries for the pseudo-types either. So add some. "make reformat-dat-files" turned up some formatting issues in pg_amop.dat, too, so fix those in passing. No catversion bump since the backend doesn't care too much what is in pg_description.
2018-09-20 22:06:18 +02:00
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(point,point)', amopmethod => 'spgist',
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
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',
amoprighttype => 'point', amopstrategy => '11', amopopr => '>^(point,point)',
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',
amoprighttype => 'point', amopstrategy => '10', amopopr => '<^(point,point)',
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' },
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
2018-09-19 00:54:10 +02:00
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
Add missing pg_description strings for pg_type entries. I noticed that all non-composite, non-array entries in pg_type.dat had descr strings, except for "json" and the pseudo-types. The lack for json seems certainly an oversight, and there's surely little reason to not have entries for the pseudo-types either. So add some. "make reformat-dat-files" turned up some formatting issues in pg_amop.dat, too, so fix those in passing. No catversion bump since the backend doesn't care too much what is in pg_description.
2018-09-20 22:06:18 +02:00
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(point,point)', amopmethod => 'spgist',
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
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' },
GIN support for @@ and @? jsonpath operators This commit makes existing GIN operator classes jsonb_ops and json_path_ops support "jsonb @@ jsonpath" and "jsonb @? jsonpath" operators. Basic idea is to extract statements of following form out of jsonpath. key1.key2. ... .keyN = const The rest of jsonpath is rechecked from heap. Catversion is bumped. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Nikita Glukhov, Alexander Korotkov Reviewed-by: Jonathan Katz, Pavel Stehule
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' },
GIN support for @@ and @? jsonpath operators This commit makes existing GIN operator classes jsonb_ops and json_path_ops support "jsonb @@ jsonpath" and "jsonb @? jsonpath" operators. Basic idea is to extract statements of following form out of jsonpath. key1.key2. ... .keyN = const The rest of jsonpath is rechecked from heap. Catversion is bumped. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Nikita Glukhov, Alexander Korotkov Reviewed-by: Jonathan Katz, Pavel Stehule
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' },
Add support for <-> (box, point) operator to SP-GiST box_ops Opclass support functions already can handle this operator, just catalog adjustment appears to be required. Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru Author: Nikita Glukhov Reviewed-by: Tom Lane, Alexander Korotkov
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' },
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
2018-09-19 00:54:10 +02:00
{ amopfamily => 'spgist/poly_ops', amoplefttype => 'polygon',
Add missing pg_description strings for pg_type entries. I noticed that all non-composite, non-array entries in pg_type.dat had descr strings, except for "json" and the pseudo-types. The lack for json seems certainly an oversight, and there's surely little reason to not have entries for the pseudo-types either. So add some. "make reformat-dat-files" turned up some formatting issues in pg_amop.dat, too, so fix those in passing. No catversion bump since the backend doesn't care too much what is in pg_description.
2018-09-20 22:06:18 +02:00
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(polygon,point)', amopmethod => 'spgist',
Add support for nearest-neighbor (KNN) searches to SP-GiST Currently, KNN searches were supported only by GiST. SP-GiST also capable to support them. This commit implements that support. SP-GiST scan stack is replaced with queue, which serves as stack if no ordering is specified. KNN support is provided for three SP-GIST opclasses: quad_point_ops, kd_point_ops and poly_ops (catversion is bumped). Some common parts between GiST and SP-GiST KNNs are extracted into separate functions. Discussion: https://postgr.es/m/570825e8-47d0-4732-2bf6-88d67d2d51c8%40postgrespro.ru Author: Nikita Glukhov, Alexander Korotkov based on GSoC work by Vlad Sterzhanov Review: Andrey Borodin, Alexander Korotkov
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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
# 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' },
]