rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-30 20:21:15 +02:00
Code Issues Packages Projects Releases Wiki Activity
80900d4690
postgresql/src/include/catalog/pg_amop.dat

3231 lines
164 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 copyright for 2022 Backpatch-through: 10
2022-01-08 01:04:57 +01:00
# Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# Portions Copyright (c) 1994, Regents of the University of California
#
# src/include/catalog/pg_amop.dat
#
#----------------------------------------------------------------------
[
# btree integer_ops
# default operators int2
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
amopmethod => 'btree' },
# crosstype operators int24
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
amopmethod => 'btree' },
# crosstype operators int28
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
amopmethod => 'btree' },
# default operators int4
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
amopmethod => 'btree' },
# crosstype operators int42
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
amopmethod => 'btree' },
# crosstype operators int48
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
amopmethod => 'btree' },
# default operators int8
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
amopmethod => 'btree' },
# crosstype operators int82
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
amopmethod => 'btree' },
# crosstype operators int84
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
amopmethod => 'btree' },
{ amopfamily => 'btree/integer_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
amopmethod => 'btree' },
# btree oid_ops
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
amopstrategy => '1', amopopr => '<(oid,oid)', amopmethod => 'btree' },
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
amopstrategy => '2', amopopr => '<=(oid,oid)', amopmethod => 'btree' },
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
amopstrategy => '3', amopopr => '=(oid,oid)', amopmethod => 'btree' },
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
amopstrategy => '4', amopopr => '>=(oid,oid)', amopmethod => 'btree' },
{ amopfamily => 'btree/oid_ops', amoplefttype => 'oid', amoprighttype => 'oid',
amopstrategy => '5', amopopr => '>(oid,oid)', amopmethod => 'btree' },
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' },
Hash support for row types Add hash functions for the record type as well as a hash operator family and operator class for the record type. This enables all the hash functionality for the record type such as hash-based plans for UNION/INTERSECT/EXCEPT DISTINCT, recursive queries using UNION DISTINCT, hash joins, and hash partitioning. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/38eccd35-4e2d-6767-1b3c-dada1eac3124%402ndquadrant.com
2020-11-19 09:24:37 +01:00
# record_ops
{ amopfamily => 'hash/record_ops', amoplefttype => 'record',
Run reformat-dat-files to declutter the catalog data files. Things had gotten pretty messy here, apparently mostly but not entirely the fault of the multirange patch. No functional changes.
2021-01-13 22:14:38 +01:00
amoprighttype => 'record', amopstrategy => '1', amopopr => '=(record,record)',
amopmethod => 'hash' },
Hash support for row types Add hash functions for the record type as well as a hash operator family and operator class for the record type. This enables all the hash functionality for the record type such as hash-based plans for UNION/INTERSECT/EXCEPT DISTINCT, recursive queries using UNION DISTINCT, hash joins, and hash partitioning. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/38eccd35-4e2d-6767-1b3c-dada1eac3124%402ndquadrant.com
2020-11-19 09:24:37 +01:00
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# 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',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(point,point)', amopmethod => 'gist',
amopsortfamily => 'btree/float_ops' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'box', amopstrategy => '28', amopopr => '<@(point,box)',
amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'polygon', amopstrategy => '48',
amopopr => '<@(point,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/point_ops', amoplefttype => 'point',
amoprighttype => 'circle', amopstrategy => '68',
amopopr => '<@(point,circle)', amopmethod => 'gist' },
# gist poly_ops (supports polygons)
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '1',
amopopr => '<<(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '2',
amopopr => '&<(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '3',
amopopr => '&&(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '4',
amopopr => '&>(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '5',
amopopr => '>>(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '6',
amopopr => '~=(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '7',
amopopr => '@>(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '8',
amopopr => '<@(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '9',
amopopr => '&<|(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '10',
amopopr => '<<|(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '11',
amopopr => '|>>(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'polygon', amopstrategy => '12',
amopopr => '|&>(polygon,polygon)', amopmethod => 'gist' },
{ amopfamily => 'gist/poly_ops', amoplefttype => 'polygon',
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(polygon,point)', amopmethod => 'gist',
amopsortfamily => 'btree/float_ops' },
# gist circle_ops
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '1',
amopopr => '<<(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '2',
amopopr => '&<(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '3',
amopopr => '&&(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '4',
amopopr => '&>(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '5',
amopopr => '>>(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '6',
amopopr => '~=(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '7',
amopopr => '@>(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '8',
amopopr => '<@(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '9',
amopopr => '&<|(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '10',
amopopr => '<<|(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '11',
amopopr => '|>>(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'circle', amopstrategy => '12',
amopopr => '|&>(circle,circle)', amopmethod => 'gist' },
{ amopfamily => 'gist/circle_ops', amoplefttype => 'circle',
amoprighttype => 'point', amopstrategy => '15', amoppurpose => 'o',
amopopr => '<->(circle,point)', amopmethod => 'gist',
amopsortfamily => 'btree/float_ops' },
# gin array_ops
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
amoprighttype => 'anyarray', amopstrategy => '1',
amopopr => '&&(anyarray,anyarray)', amopmethod => 'gin' },
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
amoprighttype => 'anyarray', amopstrategy => '2',
amopopr => '@>(anyarray,anyarray)', amopmethod => 'gin' },
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
amoprighttype => 'anyarray', amopstrategy => '3',
amopopr => '<@(anyarray,anyarray)', amopmethod => 'gin' },
{ amopfamily => 'gin/array_ops', amoplefttype => 'anyarray',
amoprighttype => 'anyarray', amopstrategy => '4',
amopopr => '=(anyarray,anyarray)', amopmethod => 'gin' },
# btree enum_ops
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '1',
amopopr => '<(anyenum,anyenum)', amopmethod => 'btree' },
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '2',
amopopr => '<=(anyenum,anyenum)', amopmethod => 'btree' },
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '3',
amopopr => '=(anyenum,anyenum)', amopmethod => 'btree' },
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '4',
amopopr => '>=(anyenum,anyenum)', amopmethod => 'btree' },
{ amopfamily => 'btree/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '5',
amopopr => '>(anyenum,anyenum)', amopmethod => 'btree' },
# hash enum_ops
{ amopfamily => 'hash/enum_ops', amoplefttype => 'anyenum',
amoprighttype => 'anyenum', amopstrategy => '1',
amopopr => '=(anyenum,anyenum)', amopmethod => 'hash' },
# btree tsvector_ops
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsvector', amopstrategy => '1',
amopopr => '<(tsvector,tsvector)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsvector', amopstrategy => '2',
amopopr => '<=(tsvector,tsvector)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsvector', amopstrategy => '3',
amopopr => '=(tsvector,tsvector)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsvector', amopstrategy => '4',
amopopr => '>=(tsvector,tsvector)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsvector', amopstrategy => '5',
amopopr => '>(tsvector,tsvector)', amopmethod => 'btree' },
# GiST tsvector_ops
{ amopfamily => 'gist/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsquery', amopstrategy => '1',
amopopr => '@@(tsvector,tsquery)', amopmethod => 'gist' },
# GIN tsvector_ops
{ amopfamily => 'gin/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsquery', amopstrategy => '1',
amopopr => '@@(tsvector,tsquery)', amopmethod => 'gin' },
{ amopfamily => 'gin/tsvector_ops', amoplefttype => 'tsvector',
amoprighttype => 'tsquery', amopstrategy => '2',
amopopr => '@@@(tsvector,tsquery)', amopmethod => 'gin' },
# btree tsquery_ops
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '1',
amopopr => '<(tsquery,tsquery)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '2',
amopopr => '<=(tsquery,tsquery)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '3',
amopopr => '=(tsquery,tsquery)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '4',
amopopr => '>=(tsquery,tsquery)', amopmethod => 'btree' },
{ amopfamily => 'btree/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '5',
amopopr => '>(tsquery,tsquery)', amopmethod => 'btree' },
# GiST tsquery_ops
{ amopfamily => 'gist/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '7',
amopopr => '@>(tsquery,tsquery)', amopmethod => 'gist' },
{ amopfamily => 'gist/tsquery_ops', amoplefttype => 'tsquery',
amoprighttype => 'tsquery', amopstrategy => '8',
amopopr => '<@(tsquery,tsquery)', amopmethod => 'gist' },
# btree range_ops
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '1',
amopopr => '<(anyrange,anyrange)', amopmethod => 'btree' },
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '2',
amopopr => '<=(anyrange,anyrange)', amopmethod => 'btree' },
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '3',
amopopr => '=(anyrange,anyrange)', amopmethod => 'btree' },
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '4',
amopopr => '>=(anyrange,anyrange)', amopmethod => 'btree' },
{ amopfamily => 'btree/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '5',
amopopr => '>(anyrange,anyrange)', amopmethod => 'btree' },
# hash range_ops
{ amopfamily => 'hash/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '1',
amopopr => '=(anyrange,anyrange)', amopmethod => 'hash' },
# GiST range_ops
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '1',
amopopr => '<<(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '1',
amopopr => '<<(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '2',
amopopr => '&<(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '2',
amopopr => '&<(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '3',
amopopr => '&&(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '3',
amopopr => '&&(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '4',
amopopr => '&>(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '4',
amopopr => '&>(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '5',
amopopr => '>>(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '5',
amopopr => '>>(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '6',
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '6',
amopopr => '-|-(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '7',
amopopr => '@>(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '7',
amopopr => '@>(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '8',
amopopr => '<@(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anymultirange', amopstrategy => '8',
amopopr => '<@(anyrange,anymultirange)', amopmethod => 'gist' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyelement', amopstrategy => '16',
amopopr => '@>(anyrange,anyelement)', amopmethod => 'gist' },
{ amopfamily => 'gist/range_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '18',
amopopr => '=(anyrange,anyrange)', amopmethod => 'gist' },
Add support of multirange matching to the existing range GiST indexes 6df7a9698b has introduced a set of operators between ranges and multiranges. Existing GiST indexes for ranges could easily support majority of them. This commit adds support for new operators to the existing range GiST indexes. New operators resides the same strategy numbers as existing ones. Appropriate check function is determined using the subtype. Catversion is bumped.
2020-12-29 21:36:43 +01:00
# GiST multirange_ops
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '1',
amopopr => '<<(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '1',
amopopr => '<<(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '2',
amopopr => '&<(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '2',
amopopr => '&<(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '3',
amopopr => '&&(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '3',
amopopr => '&&(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '4',
amopopr => '&>(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '4',
amopopr => '&>(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '5',
amopopr => '>>(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '5',
amopopr => '>>(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '6',
amopopr => '-|-(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '6',
amopopr => '-|-(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '7',
amopopr => '@>(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '7',
amopopr => '@>(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '8',
amopopr => '<@(anymultirange,anymultirange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyrange', amopstrategy => '8',
amopopr => '<@(anymultirange,anyrange)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anyelement', amopstrategy => '16',
amopopr => '@>(anymultirange,anyelement)', amopmethod => 'gist' },
{ amopfamily => 'gist/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '18',
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'gist' },
Multirange datatypes Multiranges are basically sorted arrays of non-overlapping ranges with set-theoretic operations defined over them. Since v14, each range type automatically gets a corresponding multirange datatype. There are both manual and automatic mechanisms for naming multirange types. Once can specify multirange type name using multirange_type_name attribute in CREATE TYPE.  Otherwise, a multirange type name is generated automatically. If the range type name contains "range" then we change that to "multirange". Otherwise, we add "_multirange" to the end. Implementation of multiranges comes with a space-efficient internal representation format, which evades extra paddings and duplicated storage of oids.  Altogether this format allows fetching a particular range by its index in O(n). Statistic gathering and selectivity estimation are implemented for multiranges. For this purpose, stored multirange is approximated as union range without gaps. This field will likely need improvements in the future. Catversion is bumped. Discussion: https://postgr.es/m/CALNJ-vSUpQ_Y%3DjXvTxt1VYFztaBSsWVXeF1y6gTYQ4bOiWDLgQ%40mail.gmail.com Discussion: https://postgr.es/m/a0b8026459d1e6167933be2104a6174e7d40d0ab.camel%40j-davis.com#fe7218c83b08068bfffb0c5293eceda0 Author: Paul Jungwirth, revised by me Reviewed-by: David Fetter, Corey Huinker, Jeff Davis, Pavel Stehule Reviewed-by: Alvaro Herrera, Tom Lane, Isaac Morland, David G. Johnston Reviewed-by: Zhihong Yu, Alexander Korotkov
2020-12-20 05:20:33 +01:00
# btree multirange_ops
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '1',
amopopr => '<(anymultirange,anymultirange)', amopmethod => 'btree' },
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '2',
amopopr => '<=(anymultirange,anymultirange)', amopmethod => 'btree' },
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '3',
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'btree' },
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '4',
amopopr => '>=(anymultirange,anymultirange)', amopmethod => 'btree' },
{ amopfamily => 'btree/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '5',
amopopr => '>(anymultirange,anymultirange)', amopmethod => 'btree' },
# hash multirange_ops
{ amopfamily => 'hash/multirange_ops', amoplefttype => 'anymultirange',
amoprighttype => 'anymultirange', amopstrategy => '1',
amopopr => '=(anymultirange,anymultirange)', amopmethod => 'hash' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# SP-GiST quad_point_ops
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/quad_point_ops', amoplefttype => 'point',
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(point,box)',
amopmethod => 'spgist' },
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',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '11', amopopr => '|>>(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '30', amopopr => '>^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '1', amopopr => '<<(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '5', amopopr => '>>(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
Rename the "point is strictly above/below point" comparison operators. Historically these were called >^ and <^, but that is inconsistent with the similar box, polygon, and circle operators, which are named |>> and <<| respectively. Worse, the >^ and <^ names are used for *not* strict above/below tests for the box type. Hence, invent new operators following the more common naming. The old operators remain available for now, and are still accepted by the relevant index opclasses too. But there's a deprecation notice, so maybe we can get rid of them someday. Emre Hasegeli, reviewed by Pavel Borisov Discussion: https://postgr.es/m/24348.1587444160@sss.pgh.pa.us
2020-11-23 17:38:37 +01:00
amoprighttype => 'point', amopstrategy => '10', amopopr => '<<|(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '29', amopopr => '<^(point,point)',
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'point', amopstrategy => '6', amopopr => '~=(point,point)',
amopmethod => 'spgist' },
{ amopfamily => 'spgist/kd_point_ops', amoplefttype => 'point',
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(point,box)',
amopmethod => 'spgist' },
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' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom bytea
{ amopfamily => 'brin/bytea_bloom_ops', amoplefttype => 'bytea',
amoprighttype => 'bytea', amopstrategy => '1', amopopr => '=(bytea,bytea)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax "char"
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '1', amopopr => '<(char,char)',
amopmethod => 'brin' },
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '2', amopopr => '<=(char,char)',
amopmethod => 'brin' },
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '3', amopopr => '=(char,char)',
amopmethod => 'brin' },
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '4', amopopr => '>=(char,char)',
amopmethod => 'brin' },
{ amopfamily => 'brin/char_minmax_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '5', amopopr => '>(char,char)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom "char"
{ amopfamily => 'brin/char_bloom_ops', amoplefttype => 'char',
amoprighttype => 'char', amopstrategy => '1', amopopr => '=(char,char)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax name
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '1', amopopr => '<(name,name)',
amopmethod => 'brin' },
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '2', amopopr => '<=(name,name)',
amopmethod => 'brin' },
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '3', amopopr => '=(name,name)',
amopmethod => 'brin' },
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '4', amopopr => '>=(name,name)',
amopmethod => 'brin' },
{ amopfamily => 'brin/name_minmax_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '5', amopopr => '>(name,name)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom name
{ amopfamily => 'brin/name_bloom_ops', amoplefttype => 'name',
amoprighttype => 'name', amopstrategy => '1', amopopr => '=(name,name)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax integer
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi integer
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int8,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int8',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int8,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int2,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int2',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int2,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '<(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '2', amopopr => '<=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '3', amopopr => '=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '4', amopopr => '>=(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '5', amopopr => '>(int4,int4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '<(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '2', amopopr => '<=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '3', amopopr => '=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '4', amopopr => '>=(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int2', amopstrategy => '5', amopopr => '>(int4,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '<(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '2', amopopr => '<=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '3', amopopr => '=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '4', amopopr => '>=(int4,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_minmax_multi_ops', amoplefttype => 'int4',
amoprighttype => 'int8', amopstrategy => '5', amopopr => '>(int4,int8)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom integer
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int8',
amoprighttype => 'int8', amopstrategy => '1', amopopr => '=(int8,int8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int2',
amoprighttype => 'int2', amopstrategy => '1', amopopr => '=(int2,int2)',
amopmethod => 'brin' },
{ amopfamily => 'brin/integer_bloom_ops', amoplefttype => 'int4',
amoprighttype => 'int4', amopstrategy => '1', amopopr => '=(int4,int4)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax text
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '1', amopopr => '<(text,text)',
amopmethod => 'brin' },
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '2', amopopr => '<=(text,text)',
amopmethod => 'brin' },
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '3', amopopr => '=(text,text)',
amopmethod => 'brin' },
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '4', amopopr => '>=(text,text)',
amopmethod => 'brin' },
{ amopfamily => 'brin/text_minmax_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '5', amopopr => '>(text,text)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom text
{ amopfamily => 'brin/text_bloom_ops', amoplefttype => 'text',
amoprighttype => 'text', amopstrategy => '1', amopopr => '=(text,text)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax oid
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '1', amopopr => '<(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '2', amopopr => '<=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '3', amopopr => '=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '4', amopopr => '>=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '5', amopopr => '>(oid,oid)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi oid
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '1', amopopr => '<(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '2', amopopr => '<=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '3', amopopr => '=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '4', amopopr => '>=(oid,oid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/oid_minmax_multi_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '5', amopopr => '>(oid,oid)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom oid
{ amopfamily => 'brin/oid_bloom_ops', amoplefttype => 'oid',
amoprighttype => 'oid', amopstrategy => '1', amopopr => '=(oid,oid)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax tid
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '1', amopopr => '<(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '2', amopopr => '<=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '3', amopopr => '=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '4', amopopr => '>=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '5', amopopr => '>(tid,tid)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# tid oid
{ amopfamily => 'brin/tid_bloom_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '1', amopopr => '=(tid,tid)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi tid
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '1', amopopr => '<(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '2', amopopr => '<=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '3', amopopr => '=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '4', amopopr => '>=(tid,tid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/tid_minmax_multi_ops', amoplefttype => 'tid',
amoprighttype => 'tid', amopstrategy => '5', amopopr => '>(tid,tid)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax float (float4, float8)
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '2',
amopopr => '<=(float4,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '4',
amopopr => '>=(float4,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '2',
amopopr => '<=(float4,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '4',
amopopr => '>=(float4,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '2',
amopopr => '<=(float8,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '4',
amopopr => '>=(float8,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float8,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '2',
amopopr => '<=(float8,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float8,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '4',
amopopr => '>=(float8,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float8,float8)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi float (float4, float8)
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '2',
amopopr => '<=(float4,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '4',
amopopr => '>=(float4,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '2',
amopopr => '<=(float4,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '4',
amopopr => '>=(float4,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float4',
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float4,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '1', amopopr => '<(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '2',
amopopr => '<=(float8,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '3', amopopr => '=(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '4',
amopopr => '>=(float8,float4)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float4', amopstrategy => '5', amopopr => '>(float8,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '1', amopopr => '<(float8,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '2',
amopopr => '<=(float8,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '3', amopopr => '=(float8,float8)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '4',
amopopr => '>=(float8,float8)', amopmethod => 'brin' },
{ amopfamily => 'brin/float_minmax_multi_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '5', amopopr => '>(float8,float8)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom float
{ amopfamily => 'brin/float_bloom_ops', amoplefttype => 'float4',
amoprighttype => 'float4', amopstrategy => '1', amopopr => '=(float4,float4)',
amopmethod => 'brin' },
{ amopfamily => 'brin/float_bloom_ops', amoplefttype => 'float8',
amoprighttype => 'float8', amopstrategy => '1', amopopr => '=(float8,float8)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax macaddr
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '1',
amopopr => '<(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '2',
amopopr => '<=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '3',
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '4',
amopopr => '>=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '5',
amopopr => '>(macaddr,macaddr)', amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi macaddr
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '1',
amopopr => '<(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '2',
amopopr => '<=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '3',
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '4',
amopopr => '>=(macaddr,macaddr)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr_minmax_multi_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '5',
amopopr => '>(macaddr,macaddr)', amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom macaddr
{ amopfamily => 'brin/macaddr_bloom_ops', amoplefttype => 'macaddr',
amoprighttype => 'macaddr', amopstrategy => '1',
amopopr => '=(macaddr,macaddr)', amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax macaddr8
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '1',
amopopr => '<(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '2',
amopopr => '<=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '3',
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '4',
amopopr => '>=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '5',
amopopr => '>(macaddr8,macaddr8)', amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi macaddr8
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '1',
amopopr => '<(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '2',
amopopr => '<=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '3',
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '4',
amopopr => '>=(macaddr8,macaddr8)', amopmethod => 'brin' },
{ amopfamily => 'brin/macaddr8_minmax_multi_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '5',
amopopr => '>(macaddr8,macaddr8)', amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom macaddr8
{ amopfamily => 'brin/macaddr8_bloom_ops', amoplefttype => 'macaddr8',
amoprighttype => 'macaddr8', amopstrategy => '1',
amopopr => '=(macaddr8,macaddr8)', amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax inet
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '1', amopopr => '<(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '2', amopopr => '<=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '3', amopopr => '=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '4', amopopr => '>=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '5', amopopr => '>(inet,inet)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi inet
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '1', amopopr => '<(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '2', amopopr => '<=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '3', amopopr => '=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '4', amopopr => '>=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_minmax_multi_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '5', amopopr => '>(inet,inet)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom inet
{ amopfamily => 'brin/network_bloom_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '1', amopopr => '=(inet,inet)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# inclusion inet
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '3', amopopr => '&&(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '7', amopopr => '>>=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '8', amopopr => '<<=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '18', amopopr => '=(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '24', amopopr => '>>(inet,inet)',
amopmethod => 'brin' },
{ amopfamily => 'brin/network_inclusion_ops', amoplefttype => 'inet',
amoprighttype => 'inet', amopstrategy => '26', amopopr => '<<(inet,inet)',
amopmethod => 'brin' },
# minmax character
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '<(bpchar,bpchar)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '2',
amopopr => '<=(bpchar,bpchar)', amopmethod => 'brin' },
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '3', amopopr => '=(bpchar,bpchar)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '4',
amopopr => '>=(bpchar,bpchar)', amopmethod => 'brin' },
{ amopfamily => 'brin/bpchar_minmax_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '5', amopopr => '>(bpchar,bpchar)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom character
{ amopfamily => 'brin/bpchar_bloom_ops', amoplefttype => 'bpchar',
amoprighttype => 'bpchar', amopstrategy => '1', amopopr => '=(bpchar,bpchar)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax time without time zone
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '1', amopopr => '<(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '2', amopopr => '<=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '3', amopopr => '=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '4', amopopr => '>=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '5', amopopr => '>(time,time)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi time without time zone
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '1', amopopr => '<(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '2', amopopr => '<=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '3', amopopr => '=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '4', amopopr => '>=(time,time)',
amopmethod => 'brin' },
{ amopfamily => 'brin/time_minmax_multi_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '5', amopopr => '>(time,time)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom time without time zone
{ amopfamily => 'brin/time_bloom_ops', amoplefttype => 'time',
amoprighttype => 'time', amopstrategy => '1', amopopr => '=(time,time)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax datetime (date, timestamp, timestamptz)
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '1',
amopopr => '<(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '2',
amopopr => '<=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '3',
amopopr => '=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '4',
amopopr => '>=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '5',
amopopr => '>(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(timestamptz,timestamptz)', amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi datetime (date, timestamp, timestamptz)
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(timestamp,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(timestamp,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '1', amopopr => '<(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '2', amopopr => '<=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '3', amopopr => '=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '4', amopopr => '>=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '5', amopopr => '>(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(date,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'date',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(date,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '1',
amopopr => '<(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '2',
amopopr => '<=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '3',
amopopr => '=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '4',
amopopr => '>=(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'date', amopstrategy => '5',
amopopr => '>(timestamptz,date)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '<(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '2',
amopopr => '<=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '3',
amopopr => '=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '4',
amopopr => '>=(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamp', amopstrategy => '5',
amopopr => '>(timestamptz,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '<(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '2',
amopopr => '<=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '3',
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '4',
amopopr => '>=(timestamptz,timestamptz)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_minmax_multi_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '5',
amopopr => '>(timestamptz,timestamptz)', amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom datetime (date, timestamp, timestamptz)
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'timestamp',
amoprighttype => 'timestamp', amopstrategy => '1',
amopopr => '=(timestamp,timestamp)', amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'date',
amoprighttype => 'date', amopstrategy => '1', amopopr => '=(date,date)',
amopmethod => 'brin' },
{ amopfamily => 'brin/datetime_bloom_ops', amoplefttype => 'timestamptz',
amoprighttype => 'timestamptz', amopstrategy => '1',
amopopr => '=(timestamptz,timestamptz)', amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax interval
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '1',
amopopr => '<(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '2',
amopopr => '<=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '3',
amopopr => '=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '4',
amopopr => '>=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '5',
amopopr => '>(interval,interval)', amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi interval
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '1',
amopopr => '<(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '2',
amopopr => '<=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '3',
amopopr => '=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '4',
amopopr => '>=(interval,interval)', amopmethod => 'brin' },
{ amopfamily => 'brin/interval_minmax_multi_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '5',
amopopr => '>(interval,interval)', amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom interval
{ amopfamily => 'brin/interval_bloom_ops', amoplefttype => 'interval',
amoprighttype => 'interval', amopstrategy => '1',
amopopr => '=(interval,interval)', amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax time with time zone
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '<(timetz,timetz)',
amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '2',
amopopr => '<=(timetz,timetz)', amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '3', amopopr => '=(timetz,timetz)',
amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '4',
amopopr => '>=(timetz,timetz)', amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '5', amopopr => '>(timetz,timetz)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi time with time zone
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '<(timetz,timetz)',
amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '2',
amopopr => '<=(timetz,timetz)', amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '3', amopopr => '=(timetz,timetz)',
amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '4',
amopopr => '>=(timetz,timetz)', amopmethod => 'brin' },
{ amopfamily => 'brin/timetz_minmax_multi_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '5', amopopr => '>(timetz,timetz)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom time with time zone
{ amopfamily => 'brin/timetz_bloom_ops', amoplefttype => 'timetz',
amoprighttype => 'timetz', amopstrategy => '1', amopopr => '=(timetz,timetz)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax bit
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
amoprighttype => 'bit', amopstrategy => '1', amopopr => '<(bit,bit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
amoprighttype => 'bit', amopstrategy => '2', amopopr => '<=(bit,bit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
amoprighttype => 'bit', amopstrategy => '3', amopopr => '=(bit,bit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
amoprighttype => 'bit', amopstrategy => '4', amopopr => '>=(bit,bit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/bit_minmax_ops', amoplefttype => 'bit',
amoprighttype => 'bit', amopstrategy => '5', amopopr => '>(bit,bit)',
amopmethod => 'brin' },
# minmax bit varying
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
amoprighttype => 'varbit', amopstrategy => '1', amopopr => '<(varbit,varbit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
amoprighttype => 'varbit', amopstrategy => '2',
amopopr => '<=(varbit,varbit)', amopmethod => 'brin' },
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
amoprighttype => 'varbit', amopstrategy => '3', amopopr => '=(varbit,varbit)',
amopmethod => 'brin' },
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
amoprighttype => 'varbit', amopstrategy => '4',
amopopr => '>=(varbit,varbit)', amopmethod => 'brin' },
{ amopfamily => 'brin/varbit_minmax_ops', amoplefttype => 'varbit',
amoprighttype => 'varbit', amopstrategy => '5', amopopr => '>(varbit,varbit)',
amopmethod => 'brin' },
# minmax numeric
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '1',
amopopr => '<(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '2',
amopopr => '<=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '3',
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '4',
amopopr => '>=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '5',
amopopr => '>(numeric,numeric)', amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi numeric
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '1',
amopopr => '<(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '2',
amopopr => '<=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '3',
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '4',
amopopr => '>=(numeric,numeric)', amopmethod => 'brin' },
{ amopfamily => 'brin/numeric_minmax_multi_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '5',
amopopr => '>(numeric,numeric)', amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom numeric
{ amopfamily => 'brin/numeric_bloom_ops', amoplefttype => 'numeric',
amoprighttype => 'numeric', amopstrategy => '1',
amopopr => '=(numeric,numeric)', amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# minmax uuid
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '<(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '2', amopopr => '<=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '3', amopopr => '=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '4', amopopr => '>=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '5', amopopr => '>(uuid,uuid)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi uuid
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '<(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '2', amopopr => '<=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '3', amopopr => '=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '4', amopopr => '>=(uuid,uuid)',
amopmethod => 'brin' },
{ amopfamily => 'brin/uuid_minmax_multi_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '5', amopopr => '>(uuid,uuid)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom uuid
{ amopfamily => 'brin/uuid_bloom_ops', amoplefttype => 'uuid',
amoprighttype => 'uuid', amopstrategy => '1', amopopr => '=(uuid,uuid)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# inclusion range types
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '1',
amopopr => '<<(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '2',
amopopr => '&<(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '3',
amopopr => '&&(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '4',
amopopr => '&>(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '5',
amopopr => '>>(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '7',
amopopr => '@>(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '8',
amopopr => '<@(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyelement', amopstrategy => '16',
amopopr => '@>(anyrange,anyelement)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '17',
amopopr => '-|-(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '18',
amopopr => '=(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '20',
amopopr => '<(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '21',
amopopr => '<=(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '22',
amopopr => '>(anyrange,anyrange)', amopmethod => 'brin' },
{ amopfamily => 'brin/range_inclusion_ops', amoplefttype => 'anyrange',
amoprighttype => 'anyrange', amopstrategy => '23',
amopopr => '>=(anyrange,anyrange)', amopmethod => 'brin' },
# minmax pg_lsn
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '<(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '2',
amopopr => '<=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '3', amopopr => '=(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '4',
amopopr => '>=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '5', amopopr => '>(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
BRIN minmax-multi indexes Adds BRIN opclasses similar to the existing minmax, except that instead of summarizing the page range into a single [min,max] range, the summary consists of multiple ranges and/or points, allowing gaps. This allows more efficient handling of data with poor correlation to physical location within the table and/or outlier values, for which the regular minmax opclassed tend to work poorly. It's possible to specify the number of values kept for each page range, either as a single point or an interval boundary. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_minmax_multi_ops(values_per_range=16)); When building the summary, the values are combined into intervals with the goal to minimize the "covering" (sum of interval lengths), using a support procedure computing distance between two values. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:54:29 +01:00
# minmax multi pg_lsn
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '<(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '2',
amopopr => '<=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '3', amopopr => '=(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '4',
amopopr => '>=(pg_lsn,pg_lsn)', amopmethod => 'brin' },
{ amopfamily => 'brin/pg_lsn_minmax_multi_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '5', amopopr => '>(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
BRIN bloom indexes Adds a BRIN opclass using a Bloom filter to summarize the range. Indexes using the new opclasses allow only equality queries (similar to hash indexes), but that works fine for data like UUID, MAC addresses etc. for which range queries are not very common. This also means the indexes work for data that is not well correlated to physical location within the table, or perhaps even entirely random (which is a common issue with existing BRIN minmax opclasses). It's possible to specify opclass parameters with the usual Bloom filter parameters, i.e. the desired false-positive rate and the expected number of distinct values per page range. CREATE TABLE t (a int); CREATE INDEX ON t USING brin (a int4_bloom_ops(false_positive_rate = 0.05, n_distinct_per_range = 100)); The opclasses do not operate on the indexed values directly, but compute a 32-bit hash first, and the Bloom filter is built on the hash value. Collisions should not be a huge issue though, as the number of distinct values in a page ranges is usually fairly small. Bump catversion, due to various catalog changes. Author: Tomas Vondra <tomas.vondra@postgresql.org> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Sokolov Yura <y.sokolov@postgrespro.ru> Reviewed-by: Nico Williams <nico@cryptonector.com> Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://postgr.es/m/c1138ead-7668-f0e1-0638-c3be3237e812@2ndquadrant.com Discussion: https://postgr.es/m/5d78b774-7e9c-c94e-12cf-fef51cc89b1a%402ndquadrant.com
2021-03-26 13:35:29 +01:00
# bloom pg_lsn
{ amopfamily => 'brin/pg_lsn_bloom_ops', amoplefttype => 'pg_lsn',
amoprighttype => 'pg_lsn', amopstrategy => '1', amopopr => '=(pg_lsn,pg_lsn)',
amopmethod => 'brin' },
Replace our traditional initial-catalog-data format with a better design. Historically, the initial catalog data to be installed during bootstrap has been written in DATA() lines in the catalog header files. This had lots of disadvantages: the format was badly underdocumented, it was very difficult to edit the data in any mechanized way, and due to the lack of any abstraction the data was verbose, hard to read/understand, and easy to get wrong. Hence, move this data into separate ".dat" files and represent it in a way that can easily be read and rewritten by Perl scripts. The new format is essentially "key => value" for each column; while it's a bit repetitive, explicit labeling of each value makes the data far more readable and less error-prone. Provide a way to abbreviate entries by omitting field values that match a specified default value for their column. This allows removal of a large amount of repetitive boilerplate and also lowers the barrier to adding new columns. Also teach genbki.pl how to translate symbolic OID references into numeric OIDs for more cases than just "regproc"-like pg_proc references. It can now do that for regprocedure-like references (thus solving the problem that regproc is ambiguous for overloaded functions), operators, types, opfamilies, opclasses, and access methods. Use this to turn nearly all OID cross-references in the initial data into symbolic form. This represents a very large step forward in readability and error resistance of the initial catalog data. It should also reduce the difficulty of renumbering OID assignments in uncommitted patches. Also, solve the longstanding problem that frontend code that would like to use OID macros and other information from the catalog headers often had difficulty with backend-only code in the headers. To do this, arrange for all generated macros, plus such other declarations as we deem fit, to be placed in "derived" header files that are safe for frontend inclusion. (Once clients migrate to using these pg_*_d.h headers, it will be possible to get rid of the pg_*_fn.h headers, which only exist to quarantine code away from clients. That is left for follow-on patches, however.) The now-automatically-generated macros include the Anum_xxx and Natts_xxx constants that we used to have to update by hand when adding or removing catalog columns. Replace the former manual method of generating OID macros for pg_type entries with an automatic method, ensuring that all built-in types have OID macros. (But note that this patch does not change the way that OID macros for pg_proc entries are built and used. It's not clear that making that match the other catalogs would be worth extra code churn.) Add SGML documentation explaining what the new data format is and how to work with it. Despite being a very large change in the catalog headers, there is no catversion bump here, because postgres.bki and related output files haven't changed at all. John Naylor, based on ideas from various people; review and minor additional coding by me; previous review by Alvaro Herrera Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
# inclusion box
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '1', amopopr => '<<(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '2', amopopr => '&<(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '3', amopopr => '&&(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '4', amopopr => '&>(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '5', amopopr => '>>(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '6', amopopr => '~=(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '7', amopopr => '@>(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '8', amopopr => '<@(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '9', amopopr => '&<|(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '10', amopopr => '<<|(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '11', amopopr => '|>>(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'box', amopstrategy => '12', amopopr => '|&>(box,box)',
amopmethod => 'brin' },
{ amopfamily => 'brin/box_inclusion_ops', amoplefttype => 'box',
amoprighttype => 'point', amopstrategy => '7', amopopr => '@>(box,point)',
amopmethod => 'brin' },
]
Reference in New Issue Copy Permalink