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

3477 lines
187 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_operator.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_operator 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 2021 Backpatch-through: 9.5
2021-01-02 19:06:25 +01:00
# Portions Copyright (c) 1996-2021, 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_operator.dat
#
#----------------------------------------------------------------------
[
# Note: every entry in pg_operator.dat is expected to have a 'descr' comment.
# If the operator is a deprecated equivalent of some other entry, be sure
# to comment it as such so that initdb doesn't think it's a preferred name
# for the underlying function.
{ oid => '15', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int4',
oprright => 'int8', oprresult => 'bool', oprcom => '=(int8,int4)',
oprnegate => '<>(int4,int8)', oprcode => 'int48eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '36', descr => 'not equal',
oprname => '<>', oprleft => 'int4', oprright => 'int8', oprresult => 'bool',
oprcom => '<>(int8,int4)', oprnegate => '=(int4,int8)', oprcode => 'int48ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '37', descr => 'less than',
oprname => '<', oprleft => 'int4', oprright => 'int8', oprresult => 'bool',
oprcom => '>(int8,int4)', oprnegate => '>=(int4,int8)', oprcode => 'int48lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '76', descr => 'greater than',
oprname => '>', oprleft => 'int4', oprright => 'int8', oprresult => 'bool',
oprcom => '<(int8,int4)', oprnegate => '<=(int4,int8)', oprcode => 'int48gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '80', descr => 'less than or equal',
oprname => '<=', oprleft => 'int4', oprright => 'int8', oprresult => 'bool',
oprcom => '>=(int8,int4)', oprnegate => '>(int4,int8)', oprcode => 'int48le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '82', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int4', oprright => 'int8', oprresult => 'bool',
oprcom => '<=(int8,int4)', oprnegate => '<(int4,int8)', oprcode => 'int48ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '58', descr => 'less than',
oprname => '<', oprleft => 'bool', oprright => 'bool', oprresult => 'bool',
oprcom => '>(bool,bool)', oprnegate => '>=(bool,bool)', oprcode => 'boollt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '59', descr => 'greater than',
oprname => '>', oprleft => 'bool', oprright => 'bool', oprresult => 'bool',
oprcom => '<(bool,bool)', oprnegate => '<=(bool,bool)', oprcode => 'boolgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '85', oid_symbol => 'BooleanNotEqualOperator', descr => 'not equal',
oprname => '<>', oprleft => 'bool', oprright => 'bool', oprresult => 'bool',
oprcom => '<>(bool,bool)', oprnegate => '=(bool,bool)', oprcode => 'boolne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '91', oid_symbol => 'BooleanEqualOperator', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'bool',
oprright => 'bool', oprresult => 'bool', oprcom => '=(bool,bool)',
oprnegate => '<>(bool,bool)', oprcode => 'booleq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1694', descr => 'less than or equal',
oprname => '<=', oprleft => 'bool', oprright => 'bool', oprresult => 'bool',
oprcom => '>=(bool,bool)', oprnegate => '>(bool,bool)', oprcode => 'boolle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1695', descr => 'greater than or equal',
oprname => '>=', oprleft => 'bool', oprright => 'bool', oprresult => 'bool',
oprcom => '<=(bool,bool)', oprnegate => '<(bool,bool)', oprcode => 'boolge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '92', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'char',
oprright => 'char', oprresult => 'bool', oprcom => '=(char,char)',
oprnegate => '<>(char,char)', oprcode => 'chareq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '93', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'name',
oprright => 'name', oprresult => 'bool', oprcom => '=(name,name)',
oprnegate => '<>(name,name)', oprcode => 'nameeq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '94', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int2',
oprright => 'int2', oprresult => 'bool', oprcom => '=(int2,int2)',
oprnegate => '<>(int2,int2)', oprcode => 'int2eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '95', descr => 'less than',
oprname => '<', oprleft => 'int2', oprright => 'int2', oprresult => 'bool',
oprcom => '>(int2,int2)', oprnegate => '>=(int2,int2)', oprcode => 'int2lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '96', oid_symbol => 'Int4EqualOperator', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int4',
oprright => 'int4', oprresult => 'bool', oprcom => '=(int4,int4)',
oprnegate => '<>(int4,int4)', oprcode => 'int4eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '97', oid_symbol => 'Int4LessOperator', descr => 'less than',
oprname => '<', oprleft => 'int4', oprright => 'int4', oprresult => 'bool',
oprcom => '>(int4,int4)', oprnegate => '>=(int4,int4)', oprcode => 'int4lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '98', oid_symbol => 'TextEqualOperator', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'text',
oprright => 'text', oprresult => 'bool', oprcom => '=(text,text)',
oprnegate => '<>(text,text)', oprcode => 'texteq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '3877', descr => 'starts with',
oprname => '^@', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcode => 'starts_with', oprrest => 'prefixsel',
oprjoin => 'prefixjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '254', oid_symbol => 'NameEqualTextOperator', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'name',
oprright => 'text', oprresult => 'bool', oprcom => '=(text,name)',
oprnegate => '<>(name,text)', oprcode => 'nameeqtext', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '255', oid_symbol => 'NameLessTextOperator', descr => 'less than',
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
oprname => '<', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprcom => '>(text,name)', oprnegate => '>=(name,text)',
oprcode => 'namelttext', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '256', descr => 'less than or equal',
oprname => '<=', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprcom => '>=(text,name)', oprnegate => '>(name,text)',
oprcode => 'nameletext', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '257', oid_symbol => 'NameGreaterEqualTextOperator',
descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprcom => '<=(text,name)', oprnegate => '<(name,text)',
oprcode => 'namegetext', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '258', descr => 'greater than',
oprname => '>', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprcom => '<(text,name)', oprnegate => '<=(name,text)',
oprcode => 'namegttext', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '259', descr => 'not equal',
oprname => '<>', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprcom => '<>(text,name)', oprnegate => '=(name,text)',
oprcode => 'namenetext', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '260', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'text',
oprright => 'name', oprresult => 'bool', oprcom => '=(name,text)',
oprnegate => '<>(text,name)', oprcode => 'texteqname', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '261', descr => 'less than',
oprname => '<', oprleft => 'text', oprright => 'name', oprresult => 'bool',
oprcom => '>(name,text)', oprnegate => '>=(text,name)',
oprcode => 'textltname', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '262', descr => 'less than or equal',
oprname => '<=', oprleft => 'text', oprright => 'name', oprresult => 'bool',
oprcom => '>=(name,text)', oprnegate => '>(text,name)',
oprcode => 'textlename', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '263', descr => 'greater than or equal',
oprname => '>=', oprleft => 'text', oprright => 'name', oprresult => 'bool',
oprcom => '<=(name,text)', oprnegate => '<(text,name)',
oprcode => 'textgename', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '264', descr => 'greater than',
oprname => '>', oprleft => 'text', oprright => 'name', oprresult => 'bool',
oprcom => '<(name,text)', oprnegate => '<=(text,name)',
oprcode => 'textgtname', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '265', descr => 'not equal',
oprname => '<>', oprleft => 'text', oprright => 'name', oprresult => 'bool',
oprcom => '<>(name,text)', oprnegate => '=(text,name)',
oprcode => 'textnename', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
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
{ oid => '349', descr => 'append element onto end of array',
Declare assorted array functions using anycompatible not anyelement. Convert array_append, array_prepend, array_cat, array_position, array_positions, array_remove, array_replace, and width_bucket to use anycompatiblearray. This is a simple extension of commit 5c292e6b9 to hit some other places where there's a pretty obvious gain in usability from doing so. Ideally we'd also modify other functions taking multiple old-style polymorphic arguments. But most of the remainder are tied into one or more operator classes, making any such change a much larger can of worms than I desire to open right now. Discussion: https://postgr.es/m/77675130-89da-dab1-51dd-492c93dcf5d1@postgresfriends.org
2020-11-04 22:09:55 +01:00
oprname => '||', oprleft => 'anycompatiblearray', oprright => 'anycompatible',
oprresult => 'anycompatiblearray', oprcode => 'array_append' },
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
{ oid => '374', descr => 'prepend element onto front of array',
Declare assorted array functions using anycompatible not anyelement. Convert array_append, array_prepend, array_cat, array_position, array_positions, array_remove, array_replace, and width_bucket to use anycompatiblearray. This is a simple extension of commit 5c292e6b9 to hit some other places where there's a pretty obvious gain in usability from doing so. Ideally we'd also modify other functions taking multiple old-style polymorphic arguments. But most of the remainder are tied into one or more operator classes, making any such change a much larger can of worms than I desire to open right now. Discussion: https://postgr.es/m/77675130-89da-dab1-51dd-492c93dcf5d1@postgresfriends.org
2020-11-04 22:09:55 +01:00
oprname => '||', oprleft => 'anycompatible', oprright => 'anycompatiblearray',
oprresult => 'anycompatiblearray', oprcode => 'array_prepend' },
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
{ oid => '375', descr => 'concatenate',
Declare assorted array functions using anycompatible not anyelement. Convert array_append, array_prepend, array_cat, array_position, array_positions, array_remove, array_replace, and width_bucket to use anycompatiblearray. This is a simple extension of commit 5c292e6b9 to hit some other places where there's a pretty obvious gain in usability from doing so. Ideally we'd also modify other functions taking multiple old-style polymorphic arguments. But most of the remainder are tied into one or more operator classes, making any such change a much larger can of worms than I desire to open right now. Discussion: https://postgr.es/m/77675130-89da-dab1-51dd-492c93dcf5d1@postgresfriends.org
2020-11-04 22:09:55 +01:00
oprname => '||', oprleft => 'anycompatiblearray',
oprright => 'anycompatiblearray', oprresult => 'anycompatiblearray',
oprcode => 'array_cat' },
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
{ oid => '352', descr => 'equal',
oprname => '=', oprcanhash => 't', oprleft => 'xid', oprright => 'xid',
oprresult => 'bool', oprcom => '=(xid,xid)', oprnegate => '<>(xid,xid)',
oprcode => 'xideq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '353', descr => 'equal',
oprname => '=', oprleft => 'xid', oprright => 'int4', oprresult => 'bool',
oprnegate => '<>(xid,int4)', oprcode => 'xideqint4', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '3315', descr => 'not equal',
oprname => '<>', oprleft => 'xid', oprright => 'xid', oprresult => 'bool',
oprcom => '<>(xid,xid)', oprnegate => '=(xid,xid)', oprcode => 'xidneq',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3316', descr => 'not equal',
oprname => '<>', oprleft => 'xid', oprright => 'int4', oprresult => 'bool',
oprnegate => '=(xid,int4)', oprcode => 'xidneqint4', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
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
{ oid => '5068', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'xid8',
oprright => 'xid8', oprresult => 'bool', oprcom => '=(xid8,xid8)',
oprnegate => '<>(xid8,xid8)', oprcode => 'xid8eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
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
{ oid => '5072', descr => 'not equal',
oprname => '<>', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '<>(xid8,xid8)', oprnegate => '=(xid8,xid8)', oprcode => 'xid8ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '5073', descr => 'less than',
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
oprname => '<', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '>(xid8,xid8)', oprnegate => '>=(xid8,xid8)', oprcode => 'xid8lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
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
{ oid => '5074', descr => 'greater than',
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
oprname => '>', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '<(xid8,xid8)', oprnegate => '<=(xid8,xid8)', oprcode => 'xid8gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
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
{ oid => '5075', descr => 'less than or equal',
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
oprname => '<=', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '>=(xid8,xid8)', oprnegate => '>(xid8,xid8)', oprcode => 'xid8le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
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
{ oid => '5076', descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'xid8', oprright => 'xid8', oprresult => 'bool',
oprcom => '<=(xid8,xid8)', oprnegate => '<(xid8,xid8)', oprcode => 'xid8ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
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
{ oid => '385', descr => 'equal',
oprname => '=', oprcanhash => 't', oprleft => 'cid', oprright => 'cid',
oprresult => 'bool', oprcom => '=(cid,cid)', oprcode => 'cideq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '387', oid_symbol => 'TIDEqualOperator', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'tid',
oprright => 'tid', oprresult => 'bool', oprcom => '=(tid,tid)',
oprnegate => '<>(tid,tid)', oprcode => 'tideq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
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
{ oid => '402', descr => 'not equal',
oprname => '<>', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
oprcom => '<>(tid,tid)', oprnegate => '=(tid,tid)', oprcode => 'tidne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2799', oid_symbol => 'TIDLessOperator', descr => 'less than',
oprname => '<', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
oprcom => '>(tid,tid)', oprnegate => '>=(tid,tid)', oprcode => 'tidlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
Add TID Range Scans to support efficient scanning ranges of TIDs This adds a new executor node named TID Range Scan. The query planner will generate paths for TID Range scans when quals are discovered on base relations which search for ranges on the table's ctid column. These ranges may be open at either end. For example, WHERE ctid >= '(10,0)'; will return all tuples on page 10 and over. To support this, two new optional callback functions have been added to table AM. scan_set_tidrange is used to set the scan range to just the given range of TIDs. scan_getnextslot_tidrange fetches the next tuple in the given range. For AMs were scanning ranges of TIDs would not make sense, these functions can be set to NULL in the TableAmRoutine. The query planner won't generate TID Range Scan Paths in that case. Author: Edmund Horner, David Rowley Reviewed-by: David Rowley, Tomas Vondra, Tom Lane, Andres Freund, Zhihong Yu Discussion: https://postgr.es/m/CAMyN-kB-nFTkF=VA_JPwFNo08S0d-Yk0F741S2B7LDmYAi8eyA@mail.gmail.com
2021-02-27 10:59:36 +01:00
{ oid => '2800', oid_symbol => 'TIDGreaterOperator', descr => 'greater than',
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
oprname => '>', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
oprcom => '<(tid,tid)', oprnegate => '<=(tid,tid)', oprcode => 'tidgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
Add TID Range Scans to support efficient scanning ranges of TIDs This adds a new executor node named TID Range Scan. The query planner will generate paths for TID Range scans when quals are discovered on base relations which search for ranges on the table's ctid column. These ranges may be open at either end. For example, WHERE ctid >= '(10,0)'; will return all tuples on page 10 and over. To support this, two new optional callback functions have been added to table AM. scan_set_tidrange is used to set the scan range to just the given range of TIDs. scan_getnextslot_tidrange fetches the next tuple in the given range. For AMs were scanning ranges of TIDs would not make sense, these functions can be set to NULL in the TableAmRoutine. The query planner won't generate TID Range Scan Paths in that case. Author: Edmund Horner, David Rowley Reviewed-by: David Rowley, Tomas Vondra, Tom Lane, Andres Freund, Zhihong Yu Discussion: https://postgr.es/m/CAMyN-kB-nFTkF=VA_JPwFNo08S0d-Yk0F741S2B7LDmYAi8eyA@mail.gmail.com
2021-02-27 10:59:36 +01:00
{ oid => '2801', oid_symbol => 'TIDLessEqOperator', descr => 'less than or equal',
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
oprname => '<=', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
oprcom => '>=(tid,tid)', oprnegate => '>(tid,tid)', oprcode => 'tidle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
Add TID Range Scans to support efficient scanning ranges of TIDs This adds a new executor node named TID Range Scan. The query planner will generate paths for TID Range scans when quals are discovered on base relations which search for ranges on the table's ctid column. These ranges may be open at either end. For example, WHERE ctid >= '(10,0)'; will return all tuples on page 10 and over. To support this, two new optional callback functions have been added to table AM. scan_set_tidrange is used to set the scan range to just the given range of TIDs. scan_getnextslot_tidrange fetches the next tuple in the given range. For AMs were scanning ranges of TIDs would not make sense, these functions can be set to NULL in the TableAmRoutine. The query planner won't generate TID Range Scan Paths in that case. Author: Edmund Horner, David Rowley Reviewed-by: David Rowley, Tomas Vondra, Tom Lane, Andres Freund, Zhihong Yu Discussion: https://postgr.es/m/CAMyN-kB-nFTkF=VA_JPwFNo08S0d-Yk0F741S2B7LDmYAi8eyA@mail.gmail.com
2021-02-27 10:59:36 +01:00
{ oid => '2802', oid_symbol => 'TIDGreaterEqOperator', descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
oprcom => '<=(tid,tid)', oprnegate => '<(tid,tid)', oprcode => 'tidge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '410', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int8',
oprright => 'int8', oprresult => 'bool', oprcom => '=(int8,int8)',
oprnegate => '<>(int8,int8)', oprcode => 'int8eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '411', descr => 'not equal',
oprname => '<>', oprleft => 'int8', oprright => 'int8', oprresult => 'bool',
oprcom => '<>(int8,int8)', oprnegate => '=(int8,int8)', oprcode => 'int8ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '412', oid_symbol => 'Int8LessOperator', descr => 'less than',
oprname => '<', oprleft => 'int8', oprright => 'int8', oprresult => 'bool',
oprcom => '>(int8,int8)', oprnegate => '>=(int8,int8)', oprcode => 'int8lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '413', descr => 'greater than',
oprname => '>', oprleft => 'int8', oprright => 'int8', oprresult => 'bool',
oprcom => '<(int8,int8)', oprnegate => '<=(int8,int8)', oprcode => 'int8gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '414', descr => 'less than or equal',
oprname => '<=', oprleft => 'int8', oprright => 'int8', oprresult => 'bool',
oprcom => '>=(int8,int8)', oprnegate => '>(int8,int8)', oprcode => 'int8le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '415', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int8', oprright => 'int8', oprresult => 'bool',
oprcom => '<=(int8,int8)', oprnegate => '<(int8,int8)', oprcode => 'int8ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '416', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int8',
oprright => 'int4', oprresult => 'bool', oprcom => '=(int4,int8)',
oprnegate => '<>(int8,int4)', oprcode => 'int84eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '417', descr => 'not equal',
oprname => '<>', oprleft => 'int8', oprright => 'int4', oprresult => 'bool',
oprcom => '<>(int4,int8)', oprnegate => '=(int8,int4)', oprcode => 'int84ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '418', descr => 'less than',
oprname => '<', oprleft => 'int8', oprright => 'int4', oprresult => 'bool',
oprcom => '>(int4,int8)', oprnegate => '>=(int8,int4)', oprcode => 'int84lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '419', descr => 'greater than',
oprname => '>', oprleft => 'int8', oprright => 'int4', oprresult => 'bool',
oprcom => '<(int4,int8)', oprnegate => '<=(int8,int4)', oprcode => 'int84gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '420', descr => 'less than or equal',
oprname => '<=', oprleft => 'int8', oprright => 'int4', oprresult => 'bool',
oprcom => '>=(int4,int8)', oprnegate => '>(int8,int4)', oprcode => 'int84le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '430', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int8', oprright => 'int4', oprresult => 'bool',
oprcom => '<=(int4,int8)', oprnegate => '<(int8,int4)', oprcode => 'int84ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '439', descr => 'modulus',
oprname => '%', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcode => 'int8mod' },
{ oid => '473', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'int8',
oprresult => 'int8', oprcode => 'int8abs' },
{ oid => '484', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'int8',
oprresult => 'int8', oprcode => 'int8um' },
{ oid => '485', descr => 'is left of',
oprname => '<<', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_left', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '486', descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_overleft', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '487', descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_overright', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '488', descr => 'is right of',
oprname => '>>', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_right', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '489', descr => 'is contained by',
oprname => '<@', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcom => '@>(polygon,polygon)',
oprcode => 'poly_contained', oprrest => 'contsel', oprjoin => 'contjoinsel' },
{ oid => '490', descr => 'contains',
oprname => '@>', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcom => '<@(polygon,polygon)',
oprcode => 'poly_contain', oprrest => 'contsel', oprjoin => 'contjoinsel' },
{ oid => '491', descr => 'same as',
oprname => '~=', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcom => '~=(polygon,polygon)', oprcode => 'poly_same',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '492', descr => 'overlaps',
oprname => '&&', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcom => '&&(polygon,polygon)',
oprcode => 'poly_overlap', oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '493', descr => 'is left of',
oprname => '<<', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_left', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '494', descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_overleft', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '495', descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_overright', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '496', descr => 'is right of',
oprname => '>>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_right', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '497', descr => 'is contained by',
oprname => '<@', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '@>(box,box)', oprcode => 'box_contained', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '498', descr => 'contains',
oprname => '@>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '<@(box,box)', oprcode => 'box_contain', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '499', descr => 'same as',
oprname => '~=', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '~=(box,box)', oprcode => 'box_same', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '500', descr => 'overlaps',
oprname => '&&', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '&&(box,box)', oprcode => 'box_overlap', oprrest => 'areasel',
oprjoin => 'areajoinsel' },
{ oid => '501', descr => 'greater than or equal by area',
oprname => '>=', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '<=(box,box)', oprnegate => '<(box,box)', oprcode => 'box_ge',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '502', descr => 'greater than by area',
oprname => '>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '<(box,box)', oprnegate => '<=(box,box)', oprcode => 'box_gt',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '503', descr => 'equal by area',
oprname => '=', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '=(box,box)', oprcode => 'box_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '504', descr => 'less than by area',
oprname => '<', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '>(box,box)', oprnegate => '>=(box,box)', oprcode => 'box_lt',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '505', descr => 'less than or equal by area',
oprname => '<=', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcom => '>=(box,box)', oprnegate => '>(box,box)', oprcode => 'box_le',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
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
{ oid => '506', descr => 'deprecated, use |>> instead',
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
oprname => '>^', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcode => 'point_above', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '507', descr => 'is left of',
oprname => '<<', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcode => 'point_left', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '508', descr => 'is right of',
oprname => '>>', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcode => 'point_right', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
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
{ oid => '509', descr => 'deprecated, use <<| instead',
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
oprname => '<^', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcode => 'point_below', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '510', descr => 'same as',
oprname => '~=', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcom => '~=(point,point)', oprnegate => '<>(point,point)',
oprcode => 'point_eq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '511', descr => 'point inside box',
oprname => '<@', oprleft => 'point', oprright => 'box', oprresult => 'bool',
oprcom => '@>(box,point)', oprcode => 'on_pb', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '433', descr => 'contains',
oprname => '@>', oprleft => 'box', oprright => 'point', oprresult => 'bool',
oprcom => '<@(point,box)', oprcode => 'box_contain_pt', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '512', descr => 'point within closed path, or point on open path',
oprname => '<@', oprleft => 'point', oprright => 'path', oprresult => 'bool',
oprcom => '@>(path,point)', oprcode => 'on_ppath' },
{ oid => '513', descr => 'center of',
oprname => '@@', oprkind => 'l', oprleft => '0', oprright => 'box',
oprresult => 'point', oprcode => 'box_center' },
{ oid => '514', descr => 'multiply',
oprname => '*', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcom => '*(int4,int4)', oprcode => 'int4mul' },
{ oid => '517', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,point)',
oprcode => 'point_distance' },
{ oid => '518', descr => 'not equal',
oprname => '<>', oprleft => 'int4', oprright => 'int4', oprresult => 'bool',
oprcom => '<>(int4,int4)', oprnegate => '=(int4,int4)', oprcode => 'int4ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '519', descr => 'not equal',
oprname => '<>', oprleft => 'int2', oprright => 'int2', oprresult => 'bool',
oprcom => '<>(int2,int2)', oprnegate => '=(int2,int2)', oprcode => 'int2ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '520', descr => 'greater than',
oprname => '>', oprleft => 'int2', oprright => 'int2', oprresult => 'bool',
oprcom => '<(int2,int2)', oprnegate => '<=(int2,int2)', oprcode => 'int2gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '521', descr => 'greater than',
oprname => '>', oprleft => 'int4', oprright => 'int4', oprresult => 'bool',
oprcom => '<(int4,int4)', oprnegate => '<=(int4,int4)', oprcode => 'int4gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '522', descr => 'less than or equal',
oprname => '<=', oprleft => 'int2', oprright => 'int2', oprresult => 'bool',
oprcom => '>=(int2,int2)', oprnegate => '>(int2,int2)', oprcode => 'int2le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '523', descr => 'less than or equal',
oprname => '<=', oprleft => 'int4', oprright => 'int4', oprresult => 'bool',
oprcom => '>=(int4,int4)', oprnegate => '>(int4,int4)', oprcode => 'int4le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '524', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int2', oprright => 'int2', oprresult => 'bool',
oprcom => '<=(int2,int2)', oprnegate => '<(int2,int2)', oprcode => 'int2ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '525', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int4', oprright => 'int4', oprresult => 'bool',
oprcom => '<=(int4,int4)', oprnegate => '<(int4,int4)', oprcode => 'int4ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '526', descr => 'multiply',
oprname => '*', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcom => '*(int2,int2)', oprcode => 'int2mul' },
{ oid => '527', descr => 'divide',
oprname => '/', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcode => 'int2div' },
{ oid => '528', descr => 'divide',
oprname => '/', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcode => 'int4div' },
{ oid => '529', descr => 'modulus',
oprname => '%', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcode => 'int2mod' },
{ oid => '530', descr => 'modulus',
oprname => '%', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcode => 'int4mod' },
{ oid => '531', descr => 'not equal',
oprname => '<>', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '<>(text,text)', oprnegate => '=(text,text)', oprcode => 'textne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '532', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int2',
oprright => 'int4', oprresult => 'bool', oprcom => '=(int4,int2)',
oprnegate => '<>(int2,int4)', oprcode => 'int24eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '533', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int4',
oprright => 'int2', oprresult => 'bool', oprcom => '=(int2,int4)',
oprnegate => '<>(int4,int2)', oprcode => 'int42eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '534', descr => 'less than',
oprname => '<', oprleft => 'int2', oprright => 'int4', oprresult => 'bool',
oprcom => '>(int4,int2)', oprnegate => '>=(int2,int4)', oprcode => 'int24lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '535', descr => 'less than',
oprname => '<', oprleft => 'int4', oprright => 'int2', oprresult => 'bool',
oprcom => '>(int2,int4)', oprnegate => '>=(int4,int2)', oprcode => 'int42lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '536', descr => 'greater than',
oprname => '>', oprleft => 'int2', oprright => 'int4', oprresult => 'bool',
oprcom => '<(int4,int2)', oprnegate => '<=(int2,int4)', oprcode => 'int24gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '537', descr => 'greater than',
oprname => '>', oprleft => 'int4', oprright => 'int2', oprresult => 'bool',
oprcom => '<(int2,int4)', oprnegate => '<=(int4,int2)', oprcode => 'int42gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '538', descr => 'not equal',
oprname => '<>', oprleft => 'int2', oprright => 'int4', oprresult => 'bool',
oprcom => '<>(int4,int2)', oprnegate => '=(int2,int4)', oprcode => 'int24ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '539', descr => 'not equal',
oprname => '<>', oprleft => 'int4', oprright => 'int2', oprresult => 'bool',
oprcom => '<>(int2,int4)', oprnegate => '=(int4,int2)', oprcode => 'int42ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '540', descr => 'less than or equal',
oprname => '<=', oprleft => 'int2', oprright => 'int4', oprresult => 'bool',
oprcom => '>=(int4,int2)', oprnegate => '>(int2,int4)', oprcode => 'int24le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '541', descr => 'less than or equal',
oprname => '<=', oprleft => 'int4', oprright => 'int2', oprresult => 'bool',
oprcom => '>=(int2,int4)', oprnegate => '>(int4,int2)', oprcode => 'int42le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '542', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int2', oprright => 'int4', oprresult => 'bool',
oprcom => '<=(int4,int2)', oprnegate => '<(int2,int4)', oprcode => 'int24ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '543', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int4', oprright => 'int2', oprresult => 'bool',
oprcom => '<=(int2,int4)', oprnegate => '<(int4,int2)', oprcode => 'int42ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '544', descr => 'multiply',
oprname => '*', oprleft => 'int2', oprright => 'int4', oprresult => 'int4',
oprcom => '*(int4,int2)', oprcode => 'int24mul' },
{ oid => '545', descr => 'multiply',
oprname => '*', oprleft => 'int4', oprright => 'int2', oprresult => 'int4',
oprcom => '*(int2,int4)', oprcode => 'int42mul' },
{ oid => '546', descr => 'divide',
oprname => '/', oprleft => 'int2', oprright => 'int4', oprresult => 'int4',
oprcode => 'int24div' },
{ oid => '547', descr => 'divide',
oprname => '/', oprleft => 'int4', oprright => 'int2', oprresult => 'int4',
oprcode => 'int42div' },
{ oid => '550', descr => 'add',
oprname => '+', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcom => '+(int2,int2)', oprcode => 'int2pl' },
{ oid => '551', descr => 'add',
oprname => '+', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcom => '+(int4,int4)', oprcode => 'int4pl' },
{ oid => '552', descr => 'add',
oprname => '+', oprleft => 'int2', oprright => 'int4', oprresult => 'int4',
oprcom => '+(int4,int2)', oprcode => 'int24pl' },
{ oid => '553', descr => 'add',
oprname => '+', oprleft => 'int4', oprright => 'int2', oprresult => 'int4',
oprcom => '+(int2,int4)', oprcode => 'int42pl' },
{ oid => '554', descr => 'subtract',
oprname => '-', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcode => 'int2mi' },
{ oid => '555', descr => 'subtract',
oprname => '-', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcode => 'int4mi' },
{ oid => '556', descr => 'subtract',
oprname => '-', oprleft => 'int2', oprright => 'int4', oprresult => 'int4',
oprcode => 'int24mi' },
{ oid => '557', descr => 'subtract',
oprname => '-', oprleft => 'int4', oprright => 'int2', oprresult => 'int4',
oprcode => 'int42mi' },
{ oid => '558', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'int4',
oprresult => 'int4', oprcode => 'int4um' },
{ oid => '559', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'int2',
oprresult => 'int2', oprcode => 'int2um' },
{ oid => '584', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'float4',
oprresult => 'float4', oprcode => 'float4um' },
{ oid => '585', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'float8',
oprresult => 'float8', oprcode => 'float8um' },
{ oid => '586', descr => 'add',
oprname => '+', oprleft => 'float4', oprright => 'float4',
oprresult => 'float4', oprcom => '+(float4,float4)', oprcode => 'float4pl' },
{ oid => '587', descr => 'subtract',
oprname => '-', oprleft => 'float4', oprright => 'float4',
oprresult => 'float4', oprcode => 'float4mi' },
{ oid => '588', descr => 'divide',
oprname => '/', oprleft => 'float4', oprright => 'float4',
oprresult => 'float4', oprcode => 'float4div' },
{ oid => '589', descr => 'multiply',
oprname => '*', oprleft => 'float4', oprright => 'float4',
oprresult => 'float4', oprcom => '*(float4,float4)', oprcode => 'float4mul' },
{ oid => '590', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'float4',
oprresult => 'float4', oprcode => 'float4abs' },
{ oid => '591', descr => 'add',
oprname => '+', oprleft => 'float8', oprright => 'float8',
oprresult => 'float8', oprcom => '+(float8,float8)', oprcode => 'float8pl' },
{ oid => '592', descr => 'subtract',
oprname => '-', oprleft => 'float8', oprright => 'float8',
oprresult => 'float8', oprcode => 'float8mi' },
{ oid => '593', descr => 'divide',
oprname => '/', oprleft => 'float8', oprright => 'float8',
oprresult => 'float8', oprcode => 'float8div' },
{ oid => '594', descr => 'multiply',
oprname => '*', oprleft => 'float8', oprright => 'float8',
oprresult => 'float8', oprcom => '*(float8,float8)', oprcode => 'float8mul' },
{ oid => '595', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'float8',
oprresult => 'float8', oprcode => 'float8abs' },
{ oid => '596', descr => 'square root',
oprname => '|/', oprkind => 'l', oprleft => '0', oprright => 'float8',
oprresult => 'float8', oprcode => 'dsqrt' },
{ oid => '597', descr => 'cube root',
oprname => '||/', oprkind => 'l', oprleft => '0', oprright => 'float8',
oprresult => 'float8', oprcode => 'dcbrt' },
{ oid => '607', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'oid',
oprright => 'oid', oprresult => 'bool', oprcom => '=(oid,oid)',
oprnegate => '<>(oid,oid)', oprcode => 'oideq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '608', descr => 'not equal',
oprname => '<>', oprleft => 'oid', oprright => 'oid', oprresult => 'bool',
oprcom => '<>(oid,oid)', oprnegate => '=(oid,oid)', oprcode => 'oidne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '609', descr => 'less than',
oprname => '<', oprleft => 'oid', oprright => 'oid', oprresult => 'bool',
oprcom => '>(oid,oid)', oprnegate => '>=(oid,oid)', oprcode => 'oidlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '610', descr => 'greater than',
oprname => '>', oprleft => 'oid', oprright => 'oid', oprresult => 'bool',
oprcom => '<(oid,oid)', oprnegate => '<=(oid,oid)', oprcode => 'oidgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '611', descr => 'less than or equal',
oprname => '<=', oprleft => 'oid', oprright => 'oid', oprresult => 'bool',
oprcom => '>=(oid,oid)', oprnegate => '>(oid,oid)', oprcode => 'oidle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '612', descr => 'greater than or equal',
oprname => '>=', oprleft => 'oid', oprright => 'oid', oprresult => 'bool',
oprcom => '<=(oid,oid)', oprnegate => '<(oid,oid)', oprcode => 'oidge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '644', descr => 'not equal',
oprname => '<>', oprleft => 'oidvector', oprright => 'oidvector',
oprresult => 'bool', oprcom => '<>(oidvector,oidvector)',
oprnegate => '=(oidvector,oidvector)', oprcode => 'oidvectorne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '645', descr => 'less than',
oprname => '<', oprleft => 'oidvector', oprright => 'oidvector',
oprresult => 'bool', oprcom => '>(oidvector,oidvector)',
oprnegate => '>=(oidvector,oidvector)', oprcode => 'oidvectorlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '646', descr => 'greater than',
oprname => '>', oprleft => 'oidvector', oprright => 'oidvector',
oprresult => 'bool', oprcom => '<(oidvector,oidvector)',
oprnegate => '<=(oidvector,oidvector)', oprcode => 'oidvectorgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '647', descr => 'less than or equal',
oprname => '<=', oprleft => 'oidvector', oprright => 'oidvector',
oprresult => 'bool', oprcom => '>=(oidvector,oidvector)',
oprnegate => '>(oidvector,oidvector)', oprcode => 'oidvectorle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '648', descr => 'greater than or equal',
oprname => '>=', oprleft => 'oidvector', oprright => 'oidvector',
oprresult => 'bool', oprcom => '<=(oidvector,oidvector)',
oprnegate => '<(oidvector,oidvector)', oprcode => 'oidvectorge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '649', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'oidvector',
oprright => 'oidvector', oprresult => 'bool',
oprcom => '=(oidvector,oidvector)', oprnegate => '<>(oidvector,oidvector)',
oprcode => 'oidvectoreq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '613', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'line',
Fix up handling of nondeterministic collations with pattern_ops opclasses. text_pattern_ops and its siblings can't be used with nondeterministic collations, because they use the text_eq operator which will not behave as bitwise equality if applied with a nondeterministic collation. The initial implementation of that restriction was to insert a run-time test in the related comparison functions, but that is inefficient, may throw misleading errors, and will throw errors in some cases that would work. It seems sufficient to just prevent the combination during CREATE INDEX, so do that instead. Lacking any better way to identify the opclasses involved, we need to hard-wire tests for them, which requires hand-assigned values for their OIDs, which forces a catversion bump because they previously had OIDs that would be assigned automatically. That's slightly annoying in the v12 branch, but fortunately we're not at rc1 yet, so just do it. Back-patch to v12 where nondeterministic collations were added. In passing, run make reformat-dat-files, which found some unrelated whitespace issues (slightly different ones in HEAD and v12). Peter Eisentraut, with small corrections by me Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
2019-09-21 22:29:17 +02:00
oprresult => 'float8', oprcom => '<->(line,point)', oprcode => 'dist_pl' },
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
{ oid => '760', descr => 'distance between',
oprname => '<->', oprleft => 'line', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,line)', oprcode => 'dist_lp' },
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
{ oid => '614', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'lseg',
Fix up handling of nondeterministic collations with pattern_ops opclasses. text_pattern_ops and its siblings can't be used with nondeterministic collations, because they use the text_eq operator which will not behave as bitwise equality if applied with a nondeterministic collation. The initial implementation of that restriction was to insert a run-time test in the related comparison functions, but that is inefficient, may throw misleading errors, and will throw errors in some cases that would work. It seems sufficient to just prevent the combination during CREATE INDEX, so do that instead. Lacking any better way to identify the opclasses involved, we need to hard-wire tests for them, which requires hand-assigned values for their OIDs, which forces a catversion bump because they previously had OIDs that would be assigned automatically. That's slightly annoying in the v12 branch, but fortunately we're not at rc1 yet, so just do it. Back-patch to v12 where nondeterministic collations were added. In passing, run make reformat-dat-files, which found some unrelated whitespace issues (slightly different ones in HEAD and v12). Peter Eisentraut, with small corrections by me Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
2019-09-21 22:29:17 +02:00
oprresult => 'float8', oprcom => '<->(lseg,point)', oprcode => 'dist_ps' },
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
{ oid => '761', descr => 'distance between',
oprname => '<->', oprleft => 'lseg', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,lseg)', oprcode => 'dist_sp' },
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
{ oid => '615', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'box',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprresult => 'float8', oprcom => '<->(box,point)', oprcode => 'dist_pb' },
{ oid => '606', descr => 'distance between',
oprname => '<->', oprleft => 'box', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,box)', oprcode => 'dist_bp' },
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
{ oid => '616', descr => 'distance between',
oprname => '<->', oprleft => 'lseg', oprright => 'line',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprresult => 'float8', oprcom => '<->(line,lseg)', oprcode => 'dist_sl' },
{ oid => '762', descr => 'distance between',
oprname => '<->', oprleft => 'line', oprright => 'lseg',
oprresult => 'float8', oprcom => '<->(lseg,line)', oprcode => 'dist_ls' },
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
{ oid => '617', descr => 'distance between',
oprname => '<->', oprleft => 'lseg', oprright => 'box', oprresult => 'float8',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprcom => '<->(box,lseg)', oprcode => 'dist_sb' },
{ oid => '763', descr => 'distance between',
oprname => '<->', oprleft => 'box', oprright => 'lseg', oprresult => 'float8',
oprcom => '<->(lseg,box)', oprcode => 'dist_bs' },
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
{ oid => '618', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'path',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprresult => 'float8', oprcom => '<->(path,point)', oprcode => 'dist_ppath' },
{ oid => '784', descr => 'distance between',
oprname => '<->', oprleft => 'path', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,path)', oprcode => 'dist_pathp' },
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
{ oid => '620', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'float4',
oprright => 'float4', oprresult => 'bool', oprcom => '=(float4,float4)',
oprnegate => '<>(float4,float4)', oprcode => 'float4eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '621', descr => 'not equal',
oprname => '<>', oprleft => 'float4', oprright => 'float4',
oprresult => 'bool', oprcom => '<>(float4,float4)',
oprnegate => '=(float4,float4)', oprcode => 'float4ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '622', descr => 'less than',
oprname => '<', oprleft => 'float4', oprright => 'float4',
oprresult => 'bool', oprcom => '>(float4,float4)',
oprnegate => '>=(float4,float4)', oprcode => 'float4lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '623', descr => 'greater than',
oprname => '>', oprleft => 'float4', oprright => 'float4',
oprresult => 'bool', oprcom => '<(float4,float4)',
oprnegate => '<=(float4,float4)', oprcode => 'float4gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '624', descr => 'less than or equal',
oprname => '<=', oprleft => 'float4', oprright => 'float4',
oprresult => 'bool', oprcom => '>=(float4,float4)',
oprnegate => '>(float4,float4)', oprcode => 'float4le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '625', descr => 'greater than or equal',
oprname => '>=', oprleft => 'float4', oprright => 'float4',
oprresult => 'bool', oprcom => '<=(float4,float4)',
oprnegate => '<(float4,float4)', oprcode => 'float4ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '630', descr => 'not equal',
oprname => '<>', oprleft => 'char', oprright => 'char', oprresult => 'bool',
oprcom => '<>(char,char)', oprnegate => '=(char,char)', oprcode => 'charne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '631', descr => 'less than',
oprname => '<', oprleft => 'char', oprright => 'char', oprresult => 'bool',
oprcom => '>(char,char)', oprnegate => '>=(char,char)', oprcode => 'charlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '632', descr => 'less than or equal',
oprname => '<=', oprleft => 'char', oprright => 'char', oprresult => 'bool',
oprcom => '>=(char,char)', oprnegate => '>(char,char)', oprcode => 'charle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '633', descr => 'greater than',
oprname => '>', oprleft => 'char', oprright => 'char', oprresult => 'bool',
oprcom => '<(char,char)', oprnegate => '<=(char,char)', oprcode => 'chargt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '634', descr => 'greater than or equal',
oprname => '>=', oprleft => 'char', oprright => 'char', oprresult => 'bool',
oprcom => '<=(char,char)', oprnegate => '<(char,char)', oprcode => 'charge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '639', oid_symbol => 'OID_NAME_REGEXEQ_OP',
descr => 'matches regular expression, case-sensitive',
oprname => '~', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '!~(name,text)', oprcode => 'nameregexeq',
oprrest => 'regexeqsel', oprjoin => 'regexeqjoinsel' },
{ oid => '640', descr => 'does not match regular expression, case-sensitive',
oprname => '!~', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '~(name,text)', oprcode => 'nameregexne',
oprrest => 'regexnesel', oprjoin => 'regexnejoinsel' },
{ oid => '641', oid_symbol => 'OID_TEXT_REGEXEQ_OP',
descr => 'matches regular expression, case-sensitive',
oprname => '~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '!~(text,text)', oprcode => 'textregexeq',
oprrest => 'regexeqsel', oprjoin => 'regexeqjoinsel' },
{ oid => '642', descr => 'does not match regular expression, case-sensitive',
oprname => '!~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '~(text,text)', oprcode => 'textregexne',
oprrest => 'regexnesel', oprjoin => 'regexnejoinsel' },
{ oid => '643', descr => 'not equal',
oprname => '<>', oprleft => 'name', oprright => 'name', oprresult => 'bool',
oprcom => '<>(name,name)', oprnegate => '=(name,name)', oprcode => 'namene',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '654', descr => 'concatenate',
oprname => '||', oprleft => 'text', oprright => 'text', oprresult => 'text',
oprcode => 'textcat' },
{ oid => '660', descr => 'less than',
oprname => '<', oprleft => 'name', oprright => 'name', oprresult => 'bool',
oprcom => '>(name,name)', oprnegate => '>=(name,name)', oprcode => 'namelt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '661', descr => 'less than or equal',
oprname => '<=', oprleft => 'name', oprright => 'name', oprresult => 'bool',
oprcom => '>=(name,name)', oprnegate => '>(name,name)', oprcode => 'namele',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '662', descr => 'greater than',
oprname => '>', oprleft => 'name', oprright => 'name', oprresult => 'bool',
oprcom => '<(name,name)', oprnegate => '<=(name,name)', oprcode => 'namegt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '663', descr => 'greater than or equal',
oprname => '>=', oprleft => 'name', oprright => 'name', oprresult => 'bool',
oprcom => '<=(name,name)', oprnegate => '<(name,name)', oprcode => 'namege',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '664', oid_symbol => 'TextLessOperator', descr => 'less than',
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
oprname => '<', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '>(text,text)', oprnegate => '>=(text,text)', oprcode => 'text_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '665', descr => 'less than or equal',
oprname => '<=', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '>=(text,text)', oprnegate => '>(text,text)', oprcode => 'text_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '666', descr => 'greater than',
oprname => '>', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '<(text,text)', oprnegate => '<=(text,text)', oprcode => 'text_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '667', oid_symbol => 'TextGreaterEqualOperator',
descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '<=(text,text)', oprnegate => '<(text,text)', oprcode => 'text_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '670', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'float8',
oprright => 'float8', oprresult => 'bool', oprcom => '=(float8,float8)',
oprnegate => '<>(float8,float8)', oprcode => 'float8eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '671', descr => 'not equal',
oprname => '<>', oprleft => 'float8', oprright => 'float8',
oprresult => 'bool', oprcom => '<>(float8,float8)',
oprnegate => '=(float8,float8)', oprcode => 'float8ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '672', oid_symbol => 'Float8LessOperator', descr => 'less than',
oprname => '<', oprleft => 'float8', oprright => 'float8',
oprresult => 'bool', oprcom => '>(float8,float8)',
oprnegate => '>=(float8,float8)', oprcode => 'float8lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '673', descr => 'less than or equal',
oprname => '<=', oprleft => 'float8', oprright => 'float8',
oprresult => 'bool', oprcom => '>=(float8,float8)',
oprnegate => '>(float8,float8)', oprcode => 'float8le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '674', descr => 'greater than',
oprname => '>', oprleft => 'float8', oprright => 'float8',
oprresult => 'bool', oprcom => '<(float8,float8)',
oprnegate => '<=(float8,float8)', oprcode => 'float8gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '675', descr => 'greater than or equal',
oprname => '>=', oprleft => 'float8', oprright => 'float8',
oprresult => 'bool', oprcom => '<=(float8,float8)',
oprnegate => '<(float8,float8)', oprcode => 'float8ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '682', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'int2',
oprresult => 'int2', oprcode => 'int2abs' },
{ oid => '684', descr => 'add',
oprname => '+', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcom => '+(int8,int8)', oprcode => 'int8pl' },
{ oid => '685', descr => 'subtract',
oprname => '-', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcode => 'int8mi' },
{ oid => '686', descr => 'multiply',
oprname => '*', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcom => '*(int8,int8)', oprcode => 'int8mul' },
{ oid => '687', descr => 'divide',
oprname => '/', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcode => 'int8div' },
{ oid => '688', descr => 'add',
oprname => '+', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcom => '+(int4,int8)', oprcode => 'int84pl' },
{ oid => '689', descr => 'subtract',
oprname => '-', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcode => 'int84mi' },
{ oid => '690', descr => 'multiply',
oprname => '*', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcom => '*(int4,int8)', oprcode => 'int84mul' },
{ oid => '691', descr => 'divide',
oprname => '/', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcode => 'int84div' },
{ oid => '692', descr => 'add',
oprname => '+', oprleft => 'int4', oprright => 'int8', oprresult => 'int8',
oprcom => '+(int8,int4)', oprcode => 'int48pl' },
{ oid => '693', descr => 'subtract',
oprname => '-', oprleft => 'int4', oprright => 'int8', oprresult => 'int8',
oprcode => 'int48mi' },
{ oid => '694', descr => 'multiply',
oprname => '*', oprleft => 'int4', oprright => 'int8', oprresult => 'int8',
oprcom => '*(int8,int4)', oprcode => 'int48mul' },
{ oid => '695', descr => 'divide',
oprname => '/', oprleft => 'int4', oprright => 'int8', oprresult => 'int8',
oprcode => 'int48div' },
{ oid => '818', descr => 'add',
oprname => '+', oprleft => 'int8', oprright => 'int2', oprresult => 'int8',
oprcom => '+(int2,int8)', oprcode => 'int82pl' },
{ oid => '819', descr => 'subtract',
oprname => '-', oprleft => 'int8', oprright => 'int2', oprresult => 'int8',
oprcode => 'int82mi' },
{ oid => '820', descr => 'multiply',
oprname => '*', oprleft => 'int8', oprright => 'int2', oprresult => 'int8',
oprcom => '*(int2,int8)', oprcode => 'int82mul' },
{ oid => '821', descr => 'divide',
oprname => '/', oprleft => 'int8', oprright => 'int2', oprresult => 'int8',
oprcode => 'int82div' },
{ oid => '822', descr => 'add',
oprname => '+', oprleft => 'int2', oprright => 'int8', oprresult => 'int8',
oprcom => '+(int8,int2)', oprcode => 'int28pl' },
{ oid => '823', descr => 'subtract',
oprname => '-', oprleft => 'int2', oprright => 'int8', oprresult => 'int8',
oprcode => 'int28mi' },
{ oid => '824', descr => 'multiply',
oprname => '*', oprleft => 'int2', oprright => 'int8', oprresult => 'int8',
oprcom => '*(int8,int2)', oprcode => 'int28mul' },
{ oid => '825', descr => 'divide',
oprname => '/', oprleft => 'int2', oprright => 'int8', oprresult => 'int8',
oprcode => 'int28div' },
{ oid => '706', descr => 'distance between',
oprname => '<->', oprleft => 'box', oprright => 'box', oprresult => 'float8',
oprcom => '<->(box,box)', oprcode => 'box_distance' },
{ oid => '707', descr => 'distance between',
oprname => '<->', oprleft => 'path', oprright => 'path',
oprresult => 'float8', oprcom => '<->(path,path)',
oprcode => 'path_distance' },
{ oid => '708', descr => 'distance between',
oprname => '<->', oprleft => 'line', oprright => 'line',
oprresult => 'float8', oprcom => '<->(line,line)',
oprcode => 'line_distance' },
{ oid => '709', descr => 'distance between',
oprname => '<->', oprleft => 'lseg', oprright => 'lseg',
oprresult => 'float8', oprcom => '<->(lseg,lseg)',
oprcode => 'lseg_distance' },
{ oid => '712', descr => 'distance between',
oprname => '<->', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'float8', oprcom => '<->(polygon,polygon)',
oprcode => 'poly_distance' },
{ oid => '713', descr => 'not equal',
oprname => '<>', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcom => '<>(point,point)', oprnegate => '~=(point,point)',
oprcode => 'point_ne', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
# add translation/rotation/scaling operators for geometric types. - thomas 97/05/10
{ oid => '731', descr => 'add points (translate)',
oprname => '+', oprleft => 'point', oprright => 'point', oprresult => 'point',
oprcom => '+(point,point)', oprcode => 'point_add' },
{ oid => '732', descr => 'subtract points (translate)',
oprname => '-', oprleft => 'point', oprright => 'point', oprresult => 'point',
oprcode => 'point_sub' },
{ oid => '733', descr => 'multiply points (scale/rotate)',
oprname => '*', oprleft => 'point', oprright => 'point', oprresult => 'point',
oprcom => '*(point,point)', oprcode => 'point_mul' },
{ oid => '734', descr => 'divide points (scale/rotate)',
oprname => '/', oprleft => 'point', oprright => 'point', oprresult => 'point',
oprcode => 'point_div' },
{ oid => '735', descr => 'concatenate',
oprname => '+', oprleft => 'path', oprright => 'path', oprresult => 'path',
oprcom => '+(path,path)', oprcode => 'path_add' },
{ oid => '736', descr => 'add (translate path)',
oprname => '+', oprleft => 'path', oprright => 'point', oprresult => 'path',
oprcode => 'path_add_pt' },
{ oid => '737', descr => 'subtract (translate path)',
oprname => '-', oprleft => 'path', oprright => 'point', oprresult => 'path',
oprcode => 'path_sub_pt' },
{ oid => '738', descr => 'multiply (rotate/scale path)',
oprname => '*', oprleft => 'path', oprright => 'point', oprresult => 'path',
oprcode => 'path_mul_pt' },
{ oid => '739', descr => 'divide (rotate/scale path)',
oprname => '/', oprleft => 'path', oprright => 'point', oprresult => 'path',
oprcode => 'path_div_pt' },
{ oid => '755', descr => 'contains',
oprname => '@>', oprleft => 'path', oprright => 'point', oprresult => 'bool',
oprcom => '<@(point,path)', oprcode => 'path_contain_pt' },
{ oid => '756', descr => 'is contained by',
oprname => '<@', oprleft => 'point', oprright => 'polygon',
oprresult => 'bool', oprcom => '@>(polygon,point)',
oprcode => 'pt_contained_poly', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '757', descr => 'contains',
oprname => '@>', oprleft => 'polygon', oprright => 'point',
oprresult => 'bool', oprcom => '<@(point,polygon)',
oprcode => 'poly_contain_pt', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '758', descr => 'is contained by',
oprname => '<@', oprleft => 'point', oprright => 'circle',
oprresult => 'bool', oprcom => '@>(circle,point)',
oprcode => 'pt_contained_circle', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '759', descr => 'contains',
oprname => '@>', oprleft => 'circle', oprright => 'point',
oprresult => 'bool', oprcom => '<@(point,circle)',
oprcode => 'circle_contain_pt', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '773', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'int4',
oprresult => 'int4', oprcode => 'int4abs' },
# additional operators for geometric types - thomas 1997-07-09
{ oid => '792', descr => 'equal',
oprname => '=', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcom => '=(path,path)', oprcode => 'path_n_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '793', descr => 'less than',
oprname => '<', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcom => '>(path,path)', oprcode => 'path_n_lt' },
{ oid => '794', descr => 'greater than',
oprname => '>', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcom => '<(path,path)', oprcode => 'path_n_gt' },
{ oid => '795', descr => 'less than or equal',
oprname => '<=', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcom => '>=(path,path)', oprcode => 'path_n_le' },
{ oid => '796', descr => 'greater than or equal',
oprname => '>=', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcom => '<=(path,path)', oprcode => 'path_n_ge' },
{ oid => '797', descr => 'number of points',
oprname => '#', oprkind => 'l', oprleft => '0', oprright => 'path',
oprresult => 'int4', oprcode => 'path_npoints' },
{ oid => '798', descr => 'intersect',
oprname => '?#', oprleft => 'path', oprright => 'path', oprresult => 'bool',
oprcode => 'path_inter' },
{ oid => '799', descr => 'sum of path segment lengths',
oprname => '@-@', oprkind => 'l', oprleft => '0', oprright => 'path',
oprresult => 'float8', oprcode => 'path_length' },
{ oid => '800', descr => 'is above (allows touching)',
oprname => '>^', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_above_eq', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '801', descr => 'is below (allows touching)',
oprname => '<^', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_below_eq', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '802', descr => 'deprecated, use && instead',
oprname => '?#', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_overlap', oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '803', descr => 'box intersection',
oprname => '#', oprleft => 'box', oprright => 'box', oprresult => 'box',
oprcode => 'box_intersect' },
{ oid => '804', descr => 'add point to box (translate)',
oprname => '+', oprleft => 'box', oprright => 'point', oprresult => 'box',
oprcode => 'box_add' },
{ oid => '805', descr => 'subtract point from box (translate)',
oprname => '-', oprleft => 'box', oprright => 'point', oprresult => 'box',
oprcode => 'box_sub' },
{ oid => '806', descr => 'multiply box by point (scale)',
oprname => '*', oprleft => 'box', oprright => 'point', oprresult => 'box',
oprcode => 'box_mul' },
{ oid => '807', descr => 'divide box by point (scale)',
oprname => '/', oprleft => 'box', oprright => 'point', oprresult => 'box',
oprcode => 'box_div' },
{ oid => '808', descr => 'horizontally aligned',
oprname => '?-', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcom => '?-(point,point)', oprcode => 'point_horiz' },
{ oid => '809', descr => 'vertically aligned',
oprname => '?|', oprleft => 'point', oprright => 'point', oprresult => 'bool',
oprcom => '?|(point,point)', oprcode => 'point_vert' },
{ oid => '843', descr => 'multiply',
oprname => '*', oprleft => 'money', oprright => 'float4',
oprresult => 'money', oprcom => '*(float4,money)',
oprcode => 'cash_mul_flt4' },
{ oid => '844', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'float4',
oprresult => 'money', oprcode => 'cash_div_flt4' },
{ oid => '845', descr => 'multiply',
oprname => '*', oprleft => 'float4', oprright => 'money',
oprresult => 'money', oprcom => '*(money,float4)',
oprcode => 'flt4_mul_cash' },
{ oid => '900', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'money', oprright => 'money',
oprresult => 'bool', oprcom => '=(money,money)',
oprnegate => '<>(money,money)', oprcode => 'cash_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '901', descr => 'not equal',
oprname => '<>', oprleft => 'money', oprright => 'money', oprresult => 'bool',
oprcom => '<>(money,money)', oprnegate => '=(money,money)',
oprcode => 'cash_ne', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '902', descr => 'less than',
oprname => '<', oprleft => 'money', oprright => 'money', oprresult => 'bool',
oprcom => '>(money,money)', oprnegate => '>=(money,money)',
oprcode => 'cash_lt', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '903', descr => 'greater than',
oprname => '>', oprleft => 'money', oprright => 'money', oprresult => 'bool',
oprcom => '<(money,money)', oprnegate => '<=(money,money)',
oprcode => 'cash_gt', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '904', descr => 'less than or equal',
oprname => '<=', oprleft => 'money', oprright => 'money', oprresult => 'bool',
oprcom => '>=(money,money)', oprnegate => '>(money,money)',
oprcode => 'cash_le', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '905', descr => 'greater than or equal',
oprname => '>=', oprleft => 'money', oprright => 'money', oprresult => 'bool',
oprcom => '<=(money,money)', oprnegate => '<(money,money)',
oprcode => 'cash_ge', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '906', descr => 'add',
oprname => '+', oprleft => 'money', oprright => 'money', oprresult => 'money',
oprcom => '+(money,money)', oprcode => 'cash_pl' },
{ oid => '907', descr => 'subtract',
oprname => '-', oprleft => 'money', oprright => 'money', oprresult => 'money',
oprcode => 'cash_mi' },
{ oid => '908', descr => 'multiply',
oprname => '*', oprleft => 'money', oprright => 'float8',
oprresult => 'money', oprcom => '*(float8,money)',
oprcode => 'cash_mul_flt8' },
{ oid => '909', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'float8',
oprresult => 'money', oprcode => 'cash_div_flt8' },
{ oid => '3346', descr => 'multiply',
oprname => '*', oprleft => 'money', oprright => 'int8', oprresult => 'money',
oprcom => '*(int8,money)', oprcode => 'cash_mul_int8' },
{ oid => '3347', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'int8', oprresult => 'money',
oprcode => 'cash_div_int8' },
{ oid => '912', descr => 'multiply',
oprname => '*', oprleft => 'money', oprright => 'int4', oprresult => 'money',
oprcom => '*(int4,money)', oprcode => 'cash_mul_int4' },
{ oid => '913', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'int4', oprresult => 'money',
oprcode => 'cash_div_int4' },
{ oid => '914', descr => 'multiply',
oprname => '*', oprleft => 'money', oprright => 'int2', oprresult => 'money',
oprcom => '*(int2,money)', oprcode => 'cash_mul_int2' },
{ oid => '915', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'int2', oprresult => 'money',
oprcode => 'cash_div_int2' },
{ oid => '916', descr => 'multiply',
oprname => '*', oprleft => 'float8', oprright => 'money',
oprresult => 'money', oprcom => '*(money,float8)',
oprcode => 'flt8_mul_cash' },
{ oid => '3349', descr => 'multiply',
oprname => '*', oprleft => 'int8', oprright => 'money', oprresult => 'money',
oprcom => '*(money,int8)', oprcode => 'int8_mul_cash' },
{ oid => '917', descr => 'multiply',
oprname => '*', oprleft => 'int4', oprright => 'money', oprresult => 'money',
oprcom => '*(money,int4)', oprcode => 'int4_mul_cash' },
{ oid => '918', descr => 'multiply',
oprname => '*', oprleft => 'int2', oprright => 'money', oprresult => 'money',
oprcom => '*(money,int2)', oprcode => 'int2_mul_cash' },
{ oid => '3825', descr => 'divide',
oprname => '/', oprleft => 'money', oprright => 'money',
oprresult => 'float8', oprcode => 'cash_div_cash' },
{ oid => '965', descr => 'exponentiation',
oprname => '^', oprleft => 'float8', oprright => 'float8',
oprresult => 'float8', oprcode => 'dpow' },
{ oid => '966', descr => 'add/update ACL item',
oprname => '+', oprleft => '_aclitem', oprright => 'aclitem',
oprresult => '_aclitem', oprcode => 'aclinsert' },
{ oid => '967', descr => 'remove ACL item',
oprname => '-', oprleft => '_aclitem', oprright => 'aclitem',
oprresult => '_aclitem', oprcode => 'aclremove' },
{ oid => '968', descr => 'contains',
oprname => '@>', oprleft => '_aclitem', oprright => 'aclitem',
oprresult => 'bool', oprcode => 'aclcontains' },
{ oid => '974', descr => 'equal',
oprname => '=', oprcanhash => 't', oprleft => 'aclitem',
oprright => 'aclitem', oprresult => 'bool', oprcom => '=(aclitem,aclitem)',
oprcode => 'aclitemeq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
# additional geometric operators - thomas 1997-07-09
{ oid => '969', descr => 'center of',
oprname => '@@', oprkind => 'l', oprleft => '0', oprright => 'lseg',
oprresult => 'point', oprcode => 'lseg_center' },
{ oid => '970', descr => 'center of',
oprname => '@@', oprkind => 'l', oprleft => '0', oprright => 'path',
oprresult => 'point', oprcode => 'path_center' },
{ oid => '971', descr => 'center of',
oprname => '@@', oprkind => 'l', oprleft => '0', oprright => 'polygon',
oprresult => 'point', oprcode => 'poly_center' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1054', oid_symbol => 'BpcharEqualOperator', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'bpchar',
oprright => 'bpchar', oprresult => 'bool', oprcom => '=(bpchar,bpchar)',
oprnegate => '<>(bpchar,bpchar)', oprcode => 'bpchareq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1055', oid_symbol => 'OID_BPCHAR_REGEXEQ_OP',
descr => 'matches regular expression, case-sensitive',
oprname => '~', oprleft => 'bpchar', oprright => 'text', oprresult => 'bool',
oprnegate => '!~(bpchar,text)', oprcode => 'bpcharregexeq',
oprrest => 'regexeqsel', oprjoin => 'regexeqjoinsel' },
{ oid => '1056', descr => 'does not match regular expression, case-sensitive',
oprname => '!~', oprleft => 'bpchar', oprright => 'text', oprresult => 'bool',
oprnegate => '~(bpchar,text)', oprcode => 'bpcharregexne',
oprrest => 'regexnesel', oprjoin => 'regexnejoinsel' },
{ oid => '1057', descr => 'not equal',
oprname => '<>', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '<>(bpchar,bpchar)',
oprnegate => '=(bpchar,bpchar)', oprcode => 'bpcharne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1058', oid_symbol => 'BpcharLessOperator', descr => 'less than',
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
oprname => '<', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '>(bpchar,bpchar)',
oprnegate => '>=(bpchar,bpchar)', oprcode => 'bpcharlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1059', descr => 'less than or equal',
oprname => '<=', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '>=(bpchar,bpchar)',
oprnegate => '>(bpchar,bpchar)', oprcode => 'bpcharle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1060', descr => 'greater than',
oprname => '>', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '<(bpchar,bpchar)',
oprnegate => '<=(bpchar,bpchar)', oprcode => 'bpchargt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1061', oid_symbol => 'BpcharGreaterEqualOperator',
descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '<=(bpchar,bpchar)',
oprnegate => '<(bpchar,bpchar)', oprcode => 'bpcharge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# generic array comparison operators
{ oid => '1070', oid_symbol => 'ARRAY_EQ_OP', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'anyarray',
oprright => 'anyarray', oprresult => 'bool', oprcom => '=(anyarray,anyarray)',
oprnegate => '<>(anyarray,anyarray)', oprcode => 'array_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1071', descr => 'not equal',
oprname => '<>', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '<>(anyarray,anyarray)',
oprnegate => '=(anyarray,anyarray)', oprcode => 'array_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1072', oid_symbol => 'ARRAY_LT_OP', descr => 'less than',
oprname => '<', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '>(anyarray,anyarray)',
oprnegate => '>=(anyarray,anyarray)', oprcode => 'array_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1073', oid_symbol => 'ARRAY_GT_OP', descr => 'greater than',
oprname => '>', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '<(anyarray,anyarray)',
oprnegate => '<=(anyarray,anyarray)', oprcode => 'array_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1074', descr => 'less than or equal',
oprname => '<=', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '>=(anyarray,anyarray)',
oprnegate => '>(anyarray,anyarray)', oprcode => 'array_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1075', descr => 'greater than or equal',
oprname => '>=', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '<=(anyarray,anyarray)',
oprnegate => '<(anyarray,anyarray)', oprcode => 'array_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# date operators
{ oid => '1076', descr => 'add',
oprname => '+', oprleft => 'date', oprright => 'interval',
oprresult => 'timestamp', oprcom => '+(interval,date)',
oprcode => 'date_pl_interval' },
{ oid => '1077', descr => 'subtract',
oprname => '-', oprleft => 'date', oprright => 'interval',
oprresult => 'timestamp', oprcode => 'date_mi_interval' },
{ oid => '1093', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'date',
oprright => 'date', oprresult => 'bool', oprcom => '=(date,date)',
oprnegate => '<>(date,date)', oprcode => 'date_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1094', descr => 'not equal',
oprname => '<>', oprleft => 'date', oprright => 'date', oprresult => 'bool',
oprcom => '<>(date,date)', oprnegate => '=(date,date)', oprcode => 'date_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1095', descr => 'less than',
oprname => '<', oprleft => 'date', oprright => 'date', oprresult => 'bool',
oprcom => '>(date,date)', oprnegate => '>=(date,date)', oprcode => 'date_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1096', descr => 'less than or equal',
oprname => '<=', oprleft => 'date', oprright => 'date', oprresult => 'bool',
oprcom => '>=(date,date)', oprnegate => '>(date,date)', oprcode => 'date_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1097', descr => 'greater than',
oprname => '>', oprleft => 'date', oprright => 'date', oprresult => 'bool',
oprcom => '<(date,date)', oprnegate => '<=(date,date)', oprcode => 'date_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1098', descr => 'greater than or equal',
oprname => '>=', oprleft => 'date', oprright => 'date', oprresult => 'bool',
oprcom => '<=(date,date)', oprnegate => '<(date,date)', oprcode => 'date_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1099', descr => 'subtract',
oprname => '-', oprleft => 'date', oprright => 'date', oprresult => 'int4',
oprcode => 'date_mi' },
{ oid => '1100', descr => 'add',
oprname => '+', oprleft => 'date', oprright => 'int4', oprresult => 'date',
oprcom => '+(int4,date)', oprcode => 'date_pli' },
{ oid => '1101', descr => 'subtract',
oprname => '-', oprleft => 'date', oprright => 'int4', oprresult => 'date',
oprcode => 'date_mii' },
# time operators
{ oid => '1108', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'time',
oprright => 'time', oprresult => 'bool', oprcom => '=(time,time)',
oprnegate => '<>(time,time)', oprcode => 'time_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1109', descr => 'not equal',
oprname => '<>', oprleft => 'time', oprright => 'time', oprresult => 'bool',
oprcom => '<>(time,time)', oprnegate => '=(time,time)', oprcode => 'time_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1110', descr => 'less than',
oprname => '<', oprleft => 'time', oprright => 'time', oprresult => 'bool',
oprcom => '>(time,time)', oprnegate => '>=(time,time)', oprcode => 'time_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1111', descr => 'less than or equal',
oprname => '<=', oprleft => 'time', oprright => 'time', oprresult => 'bool',
oprcom => '>=(time,time)', oprnegate => '>(time,time)', oprcode => 'time_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1112', descr => 'greater than',
oprname => '>', oprleft => 'time', oprright => 'time', oprresult => 'bool',
oprcom => '<(time,time)', oprnegate => '<=(time,time)', oprcode => 'time_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1113', descr => 'greater than or equal',
oprname => '>=', oprleft => 'time', oprright => 'time', oprresult => 'bool',
oprcom => '<=(time,time)', oprnegate => '<(time,time)', oprcode => 'time_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# timetz operators
{ oid => '1550', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'timetz',
oprright => 'timetz', oprresult => 'bool', oprcom => '=(timetz,timetz)',
oprnegate => '<>(timetz,timetz)', oprcode => 'timetz_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1551', descr => 'not equal',
oprname => '<>', oprleft => 'timetz', oprright => 'timetz',
oprresult => 'bool', oprcom => '<>(timetz,timetz)',
oprnegate => '=(timetz,timetz)', oprcode => 'timetz_ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '1552', descr => 'less than',
oprname => '<', oprleft => 'timetz', oprright => 'timetz',
oprresult => 'bool', oprcom => '>(timetz,timetz)',
oprnegate => '>=(timetz,timetz)', oprcode => 'timetz_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1553', descr => 'less than or equal',
oprname => '<=', oprleft => 'timetz', oprright => 'timetz',
oprresult => 'bool', oprcom => '>=(timetz,timetz)',
oprnegate => '>(timetz,timetz)', oprcode => 'timetz_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1554', descr => 'greater than',
oprname => '>', oprleft => 'timetz', oprright => 'timetz',
oprresult => 'bool', oprcom => '<(timetz,timetz)',
oprnegate => '<=(timetz,timetz)', oprcode => 'timetz_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1555', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timetz', oprright => 'timetz',
oprresult => 'bool', oprcom => '<=(timetz,timetz)',
oprnegate => '<(timetz,timetz)', oprcode => 'timetz_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# float48 operators
{ oid => '1116', descr => 'add',
oprname => '+', oprleft => 'float4', oprright => 'float8',
oprresult => 'float8', oprcom => '+(float8,float4)', oprcode => 'float48pl' },
{ oid => '1117', descr => 'subtract',
oprname => '-', oprleft => 'float4', oprright => 'float8',
oprresult => 'float8', oprcode => 'float48mi' },
{ oid => '1118', descr => 'divide',
oprname => '/', oprleft => 'float4', oprright => 'float8',
oprresult => 'float8', oprcode => 'float48div' },
{ oid => '1119', descr => 'multiply',
oprname => '*', oprleft => 'float4', oprright => 'float8',
oprresult => 'float8', oprcom => '*(float8,float4)',
oprcode => 'float48mul' },
{ oid => '1120', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'float4',
oprright => 'float8', oprresult => 'bool', oprcom => '=(float8,float4)',
oprnegate => '<>(float4,float8)', oprcode => 'float48eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1121', descr => 'not equal',
oprname => '<>', oprleft => 'float4', oprright => 'float8',
oprresult => 'bool', oprcom => '<>(float8,float4)',
oprnegate => '=(float4,float8)', oprcode => 'float48ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '1122', descr => 'less than',
oprname => '<', oprleft => 'float4', oprright => 'float8',
oprresult => 'bool', oprcom => '>(float8,float4)',
oprnegate => '>=(float4,float8)', oprcode => 'float48lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1123', descr => 'greater than',
oprname => '>', oprleft => 'float4', oprright => 'float8',
oprresult => 'bool', oprcom => '<(float8,float4)',
oprnegate => '<=(float4,float8)', oprcode => 'float48gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1124', descr => 'less than or equal',
oprname => '<=', oprleft => 'float4', oprright => 'float8',
oprresult => 'bool', oprcom => '>=(float8,float4)',
oprnegate => '>(float4,float8)', oprcode => 'float48le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1125', descr => 'greater than or equal',
oprname => '>=', oprleft => 'float4', oprright => 'float8',
oprresult => 'bool', oprcom => '<=(float8,float4)',
oprnegate => '<(float4,float8)', oprcode => 'float48ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# float84 operators
{ oid => '1126', descr => 'add',
oprname => '+', oprleft => 'float8', oprright => 'float4',
oprresult => 'float8', oprcom => '+(float4,float8)', oprcode => 'float84pl' },
{ oid => '1127', descr => 'subtract',
oprname => '-', oprleft => 'float8', oprright => 'float4',
oprresult => 'float8', oprcode => 'float84mi' },
{ oid => '1128', descr => 'divide',
oprname => '/', oprleft => 'float8', oprright => 'float4',
oprresult => 'float8', oprcode => 'float84div' },
{ oid => '1129', descr => 'multiply',
oprname => '*', oprleft => 'float8', oprright => 'float4',
oprresult => 'float8', oprcom => '*(float4,float8)',
oprcode => 'float84mul' },
{ oid => '1130', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'float8',
oprright => 'float4', oprresult => 'bool', oprcom => '=(float4,float8)',
oprnegate => '<>(float8,float4)', oprcode => 'float84eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1131', descr => 'not equal',
oprname => '<>', oprleft => 'float8', oprright => 'float4',
oprresult => 'bool', oprcom => '<>(float4,float8)',
oprnegate => '=(float8,float4)', oprcode => 'float84ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '1132', descr => 'less than',
oprname => '<', oprleft => 'float8', oprright => 'float4',
oprresult => 'bool', oprcom => '>(float4,float8)',
oprnegate => '>=(float8,float4)', oprcode => 'float84lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1133', descr => 'greater than',
oprname => '>', oprleft => 'float8', oprright => 'float4',
oprresult => 'bool', oprcom => '<(float4,float8)',
oprnegate => '<=(float8,float4)', oprcode => 'float84gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1134', descr => 'less than or equal',
oprname => '<=', oprleft => 'float8', oprright => 'float4',
oprresult => 'bool', oprcom => '>=(float4,float8)',
oprnegate => '>(float8,float4)', oprcode => 'float84le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1135', descr => 'greater than or equal',
oprname => '>=', oprleft => 'float8', oprright => 'float4',
oprresult => 'bool', oprcom => '<=(float4,float8)',
oprnegate => '<(float8,float4)', oprcode => 'float84ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# LIKE hacks by Keith Parks.
{ oid => '1207', oid_symbol => 'OID_NAME_LIKE_OP',
descr => 'matches LIKE expression',
oprname => '~~', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '!~~(name,text)', oprcode => 'namelike', oprrest => 'likesel',
oprjoin => 'likejoinsel' },
{ oid => '1208', descr => 'does not match LIKE expression',
oprname => '!~~', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '~~(name,text)', oprcode => 'namenlike', oprrest => 'nlikesel',
oprjoin => 'nlikejoinsel' },
{ oid => '1209', oid_symbol => 'OID_TEXT_LIKE_OP',
descr => 'matches LIKE expression',
oprname => '~~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '!~~(text,text)', oprcode => 'textlike', oprrest => 'likesel',
oprjoin => 'likejoinsel' },
{ oid => '1210', descr => 'does not match LIKE expression',
oprname => '!~~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '~~(text,text)', oprcode => 'textnlike', oprrest => 'nlikesel',
oprjoin => 'nlikejoinsel' },
{ oid => '1211', oid_symbol => 'OID_BPCHAR_LIKE_OP',
descr => 'matches LIKE expression',
oprname => '~~', oprleft => 'bpchar', oprright => 'text', oprresult => 'bool',
oprnegate => '!~~(bpchar,text)', oprcode => 'bpcharlike',
oprrest => 'likesel', oprjoin => 'likejoinsel' },
{ oid => '1212', descr => 'does not match LIKE expression',
oprname => '!~~', oprleft => 'bpchar', oprright => 'text',
oprresult => 'bool', oprnegate => '~~(bpchar,text)', oprcode => 'bpcharnlike',
oprrest => 'nlikesel', oprjoin => 'nlikejoinsel' },
# case-insensitive regex hacks
{ oid => '1226', oid_symbol => 'OID_NAME_ICREGEXEQ_OP',
descr => 'matches regular expression, case-insensitive',
oprname => '~*', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '!~*(name,text)', oprcode => 'nameicregexeq',
oprrest => 'icregexeqsel', oprjoin => 'icregexeqjoinsel' },
{ oid => '1227',
descr => 'does not match regular expression, case-insensitive',
oprname => '!~*', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '~*(name,text)', oprcode => 'nameicregexne',
oprrest => 'icregexnesel', oprjoin => 'icregexnejoinsel' },
{ oid => '1228', oid_symbol => 'OID_TEXT_ICREGEXEQ_OP',
descr => 'matches regular expression, case-insensitive',
oprname => '~*', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '!~*(text,text)', oprcode => 'texticregexeq',
oprrest => 'icregexeqsel', oprjoin => 'icregexeqjoinsel' },
{ oid => '1229',
descr => 'does not match regular expression, case-insensitive',
oprname => '!~*', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '~*(text,text)', oprcode => 'texticregexne',
oprrest => 'icregexnesel', oprjoin => 'icregexnejoinsel' },
{ oid => '1234', oid_symbol => 'OID_BPCHAR_ICREGEXEQ_OP',
descr => 'matches regular expression, case-insensitive',
oprname => '~*', oprleft => 'bpchar', oprright => 'text', oprresult => 'bool',
oprnegate => '!~*(bpchar,text)', oprcode => 'bpcharicregexeq',
oprrest => 'icregexeqsel', oprjoin => 'icregexeqjoinsel' },
{ oid => '1235',
descr => 'does not match regular expression, case-insensitive',
oprname => '!~*', oprleft => 'bpchar', oprright => 'text',
oprresult => 'bool', oprnegate => '~*(bpchar,text)',
oprcode => 'bpcharicregexne', oprrest => 'icregexnesel',
oprjoin => 'icregexnejoinsel' },
# timestamptz operators
{ oid => '1320', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't',
oprleft => 'timestamptz', oprright => 'timestamptz', oprresult => 'bool',
oprcom => '=(timestamptz,timestamptz)',
oprnegate => '<>(timestamptz,timestamptz)', oprcode => 'timestamptz_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1321', descr => 'not equal',
oprname => '<>', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<>(timestamptz,timestamptz)',
oprnegate => '=(timestamptz,timestamptz)', oprcode => 'timestamptz_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1322', descr => 'less than',
oprname => '<', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>(timestamptz,timestamptz)',
oprnegate => '>=(timestamptz,timestamptz)', oprcode => 'timestamptz_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1323', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>=(timestamptz,timestamptz)',
oprnegate => '>(timestamptz,timestamptz)', oprcode => 'timestamptz_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1324', descr => 'greater than',
oprname => '>', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<(timestamptz,timestamptz)',
oprnegate => '<=(timestamptz,timestamptz)', oprcode => 'timestamptz_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1325', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<=(timestamptz,timestamptz)',
oprnegate => '<(timestamptz,timestamptz)', oprcode => 'timestamptz_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1327', descr => 'add',
oprname => '+', oprleft => 'timestamptz', oprright => 'interval',
oprresult => 'timestamptz', oprcom => '+(interval,timestamptz)',
oprcode => 'timestamptz_pl_interval' },
{ oid => '1328', descr => 'subtract',
oprname => '-', oprleft => 'timestamptz', oprright => 'timestamptz',
oprresult => 'interval', oprcode => 'timestamptz_mi' },
{ oid => '1329', descr => 'subtract',
oprname => '-', oprleft => 'timestamptz', oprright => 'interval',
oprresult => 'timestamptz', oprcode => 'timestamptz_mi_interval' },
# interval operators
{ oid => '1330', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'interval',
oprright => 'interval', oprresult => 'bool', oprcom => '=(interval,interval)',
oprnegate => '<>(interval,interval)', oprcode => 'interval_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1331', descr => 'not equal',
oprname => '<>', oprleft => 'interval', oprright => 'interval',
oprresult => 'bool', oprcom => '<>(interval,interval)',
oprnegate => '=(interval,interval)', oprcode => 'interval_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1332', descr => 'less than',
oprname => '<', oprleft => 'interval', oprright => 'interval',
oprresult => 'bool', oprcom => '>(interval,interval)',
oprnegate => '>=(interval,interval)', oprcode => 'interval_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1333', descr => 'less than or equal',
oprname => '<=', oprleft => 'interval', oprright => 'interval',
oprresult => 'bool', oprcom => '>=(interval,interval)',
oprnegate => '>(interval,interval)', oprcode => 'interval_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1334', descr => 'greater than',
oprname => '>', oprleft => 'interval', oprright => 'interval',
oprresult => 'bool', oprcom => '<(interval,interval)',
oprnegate => '<=(interval,interval)', oprcode => 'interval_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1335', descr => 'greater than or equal',
oprname => '>=', oprleft => 'interval', oprright => 'interval',
oprresult => 'bool', oprcom => '<=(interval,interval)',
oprnegate => '<(interval,interval)', oprcode => 'interval_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1336', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'interval',
oprresult => 'interval', oprcode => 'interval_um' },
{ oid => '1337', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'interval',
oprresult => 'interval', oprcom => '+(interval,interval)',
oprcode => 'interval_pl' },
{ oid => '1338', descr => 'subtract',
oprname => '-', oprleft => 'interval', oprright => 'interval',
oprresult => 'interval', oprcode => 'interval_mi' },
{ oid => '1360', descr => 'convert date and time to timestamp',
oprname => '+', oprleft => 'date', oprright => 'time',
oprresult => 'timestamp', oprcom => '+(time,date)',
oprcode => 'datetime_pl' },
{ oid => '1361',
descr => 'convert date and time with time zone to timestamp with time zone',
oprname => '+', oprleft => 'date', oprright => 'timetz',
oprresult => 'timestamptz', oprcom => '+(timetz,date)',
oprcode => 'datetimetz_pl' },
{ oid => '1363', descr => 'convert time and date to timestamp',
oprname => '+', oprleft => 'time', oprright => 'date',
oprresult => 'timestamp', oprcom => '+(date,time)',
oprcode => 'timedate_pl' },
{ oid => '1366',
descr => 'convert time with time zone and date to timestamp with time zone',
oprname => '+', oprleft => 'timetz', oprright => 'date',
oprresult => 'timestamptz', oprcom => '+(date,timetz)',
oprcode => 'timetzdate_pl' },
{ oid => '1399', descr => 'subtract',
oprname => '-', oprleft => 'time', oprright => 'time',
oprresult => 'interval', oprcode => 'time_mi_time' },
# additional geometric operators - thomas 97/04/18
{ oid => '1420', descr => 'center of',
oprname => '@@', oprkind => 'l', oprleft => '0', oprright => 'circle',
oprresult => 'point', oprcode => 'circle_center' },
{ oid => '1500', descr => 'equal by area',
oprname => '=', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '=(circle,circle)',
oprnegate => '<>(circle,circle)', oprcode => 'circle_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1501', descr => 'not equal by area',
oprname => '<>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '<>(circle,circle)',
oprnegate => '=(circle,circle)', oprcode => 'circle_ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '1502', descr => 'less than by area',
oprname => '<', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '>(circle,circle)',
oprnegate => '>=(circle,circle)', oprcode => 'circle_lt',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '1503', descr => 'greater than by area',
oprname => '>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '<(circle,circle)',
oprnegate => '<=(circle,circle)', oprcode => 'circle_gt',
oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '1504', descr => 'less than or equal by area',
oprname => '<=', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '>=(circle,circle)',
oprnegate => '>(circle,circle)', oprcode => 'circle_le', oprrest => 'areasel',
oprjoin => 'areajoinsel' },
{ oid => '1505', descr => 'greater than or equal by area',
oprname => '>=', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '<=(circle,circle)',
oprnegate => '<(circle,circle)', oprcode => 'circle_ge', oprrest => 'areasel',
oprjoin => 'areajoinsel' },
{ oid => '1506', descr => 'is left of',
oprname => '<<', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_left', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1507', descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_overleft', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1508', descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_overright', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1509', descr => 'is right of',
oprname => '>>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_right', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1510', descr => 'is contained by',
oprname => '<@', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '@>(circle,circle)',
oprcode => 'circle_contained', oprrest => 'contsel',
oprjoin => 'contjoinsel' },
{ oid => '1511', descr => 'contains',
oprname => '@>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '<@(circle,circle)',
oprcode => 'circle_contain', oprrest => 'contsel', oprjoin => 'contjoinsel' },
{ oid => '1512', descr => 'same as',
oprname => '~=', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '~=(circle,circle)', oprcode => 'circle_same',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1513', descr => 'overlaps',
oprname => '&&', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcom => '&&(circle,circle)',
oprcode => 'circle_overlap', oprrest => 'areasel', oprjoin => 'areajoinsel' },
{ oid => '1514', descr => 'is above',
oprname => '|>>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_above', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1515', descr => 'is below',
oprname => '<<|', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_below', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '1516', descr => 'add',
oprname => '+', oprleft => 'circle', oprright => 'point',
oprresult => 'circle', oprcode => 'circle_add_pt' },
{ oid => '1517', descr => 'subtract',
oprname => '-', oprleft => 'circle', oprright => 'point',
oprresult => 'circle', oprcode => 'circle_sub_pt' },
{ oid => '1518', descr => 'multiply',
oprname => '*', oprleft => 'circle', oprright => 'point',
oprresult => 'circle', oprcode => 'circle_mul_pt' },
{ oid => '1519', descr => 'divide',
oprname => '/', oprleft => 'circle', oprright => 'point',
oprresult => 'circle', oprcode => 'circle_div_pt' },
{ oid => '1520', descr => 'distance between',
oprname => '<->', oprleft => 'circle', oprright => 'circle',
oprresult => 'float8', oprcom => '<->(circle,circle)',
oprcode => 'circle_distance' },
{ oid => '1521', descr => 'number of points',
oprname => '#', oprkind => 'l', oprleft => '0', oprright => 'polygon',
oprresult => 'int4', oprcode => 'poly_npoints' },
{ oid => '1522', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'circle',
oprresult => 'float8', oprcom => '<->(circle,point)', oprcode => 'dist_pc' },
{ oid => '3291', descr => 'distance between',
oprname => '<->', oprleft => 'circle', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,circle)',
oprcode => 'dist_cpoint' },
{ oid => '3276', descr => 'distance between',
oprname => '<->', oprleft => 'point', oprright => 'polygon',
oprresult => 'float8', oprcom => '<->(polygon,point)',
oprcode => 'dist_ppoly' },
{ oid => '3289', descr => 'distance between',
oprname => '<->', oprleft => 'polygon', oprright => 'point',
oprresult => 'float8', oprcom => '<->(point,polygon)',
oprcode => 'dist_polyp' },
{ oid => '1523', descr => 'distance between',
oprname => '<->', oprleft => 'circle', oprright => 'polygon',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprresult => 'float8', oprcom => '<->(polygon,circle)',
oprcode => 'dist_cpoly' },
{ oid => '1383', descr => 'distance between',
oprname => '<->', oprleft => 'polygon', oprright => 'circle',
oprresult => 'float8', oprcom => '<->(circle,polygon)',
oprcode => 'dist_polyc' },
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
# additional geometric operators - thomas 1997-07-09
{ oid => '1524', descr => 'distance between',
oprname => '<->', oprleft => 'line', oprright => 'box', oprresult => 'float8',
Add missing commutators for distance operators Some of <-> operators between geometric types have their commutators missed. This commit adds them. The motivation is upcoming kNN support for some of those operators. 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:55:01 +02:00
oprcom => '<->(box,line)', oprcode => 'dist_lb' },
{ oid => '1382', descr => 'distance between',
oprname => '<->', oprleft => 'box', oprright => 'line', oprresult => 'float8',
oprcom => '<->(line,box)', oprcode => 'dist_bl' },
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
{ oid => '1525', descr => 'intersect',
oprname => '?#', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '?#(lseg,lseg)', oprcode => 'lseg_intersect' },
{ oid => '1526', descr => 'parallel',
oprname => '?||', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '?||(lseg,lseg)', oprcode => 'lseg_parallel' },
{ oid => '1527', descr => 'perpendicular',
oprname => '?-|', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '?-|(lseg,lseg)', oprcode => 'lseg_perp' },
{ oid => '1528', descr => 'horizontal',
oprname => '?-', oprkind => 'l', oprleft => '0', oprright => 'lseg',
oprresult => 'bool', oprcode => 'lseg_horizontal' },
{ oid => '1529', descr => 'vertical',
oprname => '?|', oprkind => 'l', oprleft => '0', oprright => 'lseg',
oprresult => 'bool', oprcode => 'lseg_vertical' },
{ oid => '1535', descr => 'equal',
oprname => '=', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '=(lseg,lseg)', oprnegate => '<>(lseg,lseg)', oprcode => 'lseg_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1536', descr => 'intersection point',
oprname => '#', oprleft => 'lseg', oprright => 'lseg', oprresult => 'point',
oprcom => '#(lseg,lseg)', oprcode => 'lseg_interpt' },
{ oid => '1537', descr => 'intersect',
oprname => '?#', oprleft => 'lseg', oprright => 'line', oprresult => 'bool',
oprcode => 'inter_sl' },
{ oid => '1538', descr => 'intersect',
oprname => '?#', oprleft => 'lseg', oprright => 'box', oprresult => 'bool',
oprcode => 'inter_sb' },
{ oid => '1539', descr => 'intersect',
oprname => '?#', oprleft => 'line', oprright => 'box', oprresult => 'bool',
oprcode => 'inter_lb' },
{ oid => '1546', descr => 'point on line',
oprname => '<@', oprleft => 'point', oprright => 'line', oprresult => 'bool',
oprcode => 'on_pl' },
{ oid => '1547', descr => 'is contained by',
oprname => '<@', oprleft => 'point', oprright => 'lseg', oprresult => 'bool',
oprcode => 'on_ps' },
{ oid => '1548', descr => 'lseg on line',
oprname => '<@', oprleft => 'lseg', oprright => 'line', oprresult => 'bool',
oprcode => 'on_sl' },
{ oid => '1549', descr => 'is contained by',
oprname => '<@', oprleft => 'lseg', oprright => 'box', oprresult => 'bool',
oprcode => 'on_sb' },
{ oid => '1557', descr => 'closest point to A on B',
oprname => '##', oprleft => 'point', oprright => 'line', oprresult => 'point',
oprcode => 'close_pl' },
{ oid => '1558', descr => 'closest point to A on B',
oprname => '##', oprleft => 'point', oprright => 'lseg', oprresult => 'point',
oprcode => 'close_ps' },
{ oid => '1559', descr => 'closest point to A on B',
oprname => '##', oprleft => 'point', oprright => 'box', oprresult => 'point',
oprcode => 'close_pb' },
{ oid => '1566', descr => 'closest point to A on B',
oprname => '##', oprleft => 'lseg', oprright => 'line', oprresult => 'point',
oprcode => 'close_sl' },
{ oid => '1567', descr => 'closest point to A on B',
oprname => '##', oprleft => 'lseg', oprright => 'box', oprresult => 'point',
oprcode => 'close_sb' },
{ oid => '1568', descr => 'closest point to A on B',
oprname => '##', oprleft => 'line', oprright => 'box', oprresult => 'point',
oprcode => 'close_lb' },
{ oid => '1577', descr => 'closest point to A on B',
oprname => '##', oprleft => 'line', oprright => 'lseg', oprresult => 'point',
oprcode => 'close_ls' },
{ oid => '1578', descr => 'closest point to A on B',
oprname => '##', oprleft => 'lseg', oprright => 'lseg', oprresult => 'point',
oprcode => 'close_lseg' },
{ oid => '1583', descr => 'multiply',
oprname => '*', oprleft => 'interval', oprright => 'float8',
oprresult => 'interval', oprcom => '*(float8,interval)',
oprcode => 'interval_mul' },
{ oid => '1584', descr => 'multiply',
oprname => '*', oprleft => 'float8', oprright => 'interval',
oprresult => 'interval', oprcom => '*(interval,float8)',
oprcode => 'mul_d_interval' },
{ oid => '1585', descr => 'divide',
oprname => '/', oprleft => 'interval', oprright => 'float8',
oprresult => 'interval', oprcode => 'interval_div' },
{ oid => '1586', descr => 'not equal',
oprname => '<>', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '<>(lseg,lseg)', oprnegate => '=(lseg,lseg)', oprcode => 'lseg_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1587', descr => 'less than by length',
oprname => '<', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '>(lseg,lseg)', oprnegate => '>=(lseg,lseg)',
oprcode => 'lseg_lt' },
{ oid => '1588', descr => 'less than or equal by length',
oprname => '<=', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '>=(lseg,lseg)', oprnegate => '>(lseg,lseg)',
oprcode => 'lseg_le' },
{ oid => '1589', descr => 'greater than by length',
oprname => '>', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '<(lseg,lseg)', oprnegate => '<=(lseg,lseg)',
oprcode => 'lseg_gt' },
{ oid => '1590', descr => 'greater than or equal by length',
oprname => '>=', oprleft => 'lseg', oprright => 'lseg', oprresult => 'bool',
oprcom => '<=(lseg,lseg)', oprnegate => '<(lseg,lseg)',
oprcode => 'lseg_ge' },
{ oid => '1591', descr => 'distance between endpoints',
oprname => '@-@', oprkind => 'l', oprleft => '0', oprright => 'lseg',
oprresult => 'float8', oprcode => 'lseg_length' },
{ oid => '1611', descr => 'intersect',
oprname => '?#', oprleft => 'line', oprright => 'line', oprresult => 'bool',
oprcom => '?#(line,line)', oprcode => 'line_intersect' },
{ oid => '1612', descr => 'parallel',
oprname => '?||', oprleft => 'line', oprright => 'line', oprresult => 'bool',
oprcom => '?||(line,line)', oprcode => 'line_parallel' },
{ oid => '1613', descr => 'perpendicular',
oprname => '?-|', oprleft => 'line', oprright => 'line', oprresult => 'bool',
oprcom => '?-|(line,line)', oprcode => 'line_perp' },
{ oid => '1614', descr => 'horizontal',
oprname => '?-', oprkind => 'l', oprleft => '0', oprright => 'line',
oprresult => 'bool', oprcode => 'line_horizontal' },
{ oid => '1615', descr => 'vertical',
oprname => '?|', oprkind => 'l', oprleft => '0', oprright => 'line',
oprresult => 'bool', oprcode => 'line_vertical' },
{ oid => '1616', descr => 'equal',
oprname => '=', oprleft => 'line', oprright => 'line', oprresult => 'bool',
oprcom => '=(line,line)', oprcode => 'line_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1617', descr => 'intersection point',
oprname => '#', oprleft => 'line', oprright => 'line', oprresult => 'point',
oprcom => '#(line,line)', oprcode => 'line_interpt' },
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
{ oid => '4161', descr => 'is above',
oprname => '|>>', oprleft => 'point', oprright => 'point',
oprresult => 'bool', oprcode => 'point_above', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '4162', descr => 'is below',
oprname => '<<|', oprleft => 'point', oprright => 'point',
oprresult => 'bool', oprcode => 'point_below', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
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
# MACADDR type
{ oid => '1220', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'macaddr',
oprright => 'macaddr', oprresult => 'bool', oprcom => '=(macaddr,macaddr)',
oprnegate => '<>(macaddr,macaddr)', oprcode => 'macaddr_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1221', descr => 'not equal',
oprname => '<>', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'bool', oprcom => '<>(macaddr,macaddr)',
oprnegate => '=(macaddr,macaddr)', oprcode => 'macaddr_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1222', descr => 'less than',
oprname => '<', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'bool', oprcom => '>(macaddr,macaddr)',
oprnegate => '>=(macaddr,macaddr)', oprcode => 'macaddr_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1223', descr => 'less than or equal',
oprname => '<=', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'bool', oprcom => '>=(macaddr,macaddr)',
oprnegate => '>(macaddr,macaddr)', oprcode => 'macaddr_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1224', descr => 'greater than',
oprname => '>', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'bool', oprcom => '<(macaddr,macaddr)',
oprnegate => '<=(macaddr,macaddr)', oprcode => 'macaddr_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1225', descr => 'greater than or equal',
oprname => '>=', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'bool', oprcom => '<=(macaddr,macaddr)',
oprnegate => '<(macaddr,macaddr)', oprcode => 'macaddr_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '3147', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'macaddr',
oprresult => 'macaddr', oprcode => 'macaddr_not' },
{ oid => '3148', descr => 'bitwise and',
oprname => '&', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'macaddr', oprcode => 'macaddr_and' },
{ oid => '3149', descr => 'bitwise or',
oprname => '|', oprleft => 'macaddr', oprright => 'macaddr',
oprresult => 'macaddr', oprcode => 'macaddr_or' },
# MACADDR8 type
{ oid => '3362', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'macaddr8',
oprright => 'macaddr8', oprresult => 'bool', oprcom => '=(macaddr8,macaddr8)',
oprnegate => '<>(macaddr8,macaddr8)', oprcode => 'macaddr8_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '3363', descr => 'not equal',
oprname => '<>', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'bool', oprcom => '<>(macaddr8,macaddr8)',
oprnegate => '=(macaddr8,macaddr8)', oprcode => 'macaddr8_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3364', descr => 'less than',
oprname => '<', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'bool', oprcom => '>(macaddr8,macaddr8)',
oprnegate => '>=(macaddr8,macaddr8)', oprcode => 'macaddr8_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3365', descr => 'less than or equal',
oprname => '<=', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'bool', oprcom => '>=(macaddr8,macaddr8)',
oprnegate => '>(macaddr8,macaddr8)', oprcode => 'macaddr8_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3366', descr => 'greater than',
oprname => '>', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'bool', oprcom => '<(macaddr8,macaddr8)',
oprnegate => '<=(macaddr8,macaddr8)', oprcode => 'macaddr8_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3367', descr => 'greater than or equal',
oprname => '>=', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'bool', oprcom => '<=(macaddr8,macaddr8)',
oprnegate => '<(macaddr8,macaddr8)', oprcode => 'macaddr8_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '3368', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'macaddr8',
oprresult => 'macaddr8', oprcode => 'macaddr8_not' },
{ oid => '3369', descr => 'bitwise and',
oprname => '&', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'macaddr8', oprcode => 'macaddr8_and' },
{ oid => '3370', descr => 'bitwise or',
oprname => '|', oprleft => 'macaddr8', oprright => 'macaddr8',
oprresult => 'macaddr8', oprcode => 'macaddr8_or' },
# INET type (these also support CIDR via implicit cast)
{ oid => '1201', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'inet',
oprright => 'inet', oprresult => 'bool', oprcom => '=(inet,inet)',
oprnegate => '<>(inet,inet)', oprcode => 'network_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1202', descr => 'not equal',
oprname => '<>', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '<>(inet,inet)', oprnegate => '=(inet,inet)',
oprcode => 'network_ne', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1203', descr => 'less than',
oprname => '<', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '>(inet,inet)', oprnegate => '>=(inet,inet)',
oprcode => 'network_lt', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '1204', descr => 'less than or equal',
oprname => '<=', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '>=(inet,inet)', oprnegate => '>(inet,inet)',
oprcode => 'network_le', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '1205', descr => 'greater than',
oprname => '>', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '<(inet,inet)', oprnegate => '<=(inet,inet)',
oprcode => 'network_gt', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '1206', descr => 'greater than or equal',
oprname => '>=', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '<=(inet,inet)', oprnegate => '<(inet,inet)',
oprcode => 'network_ge', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '931', oid_symbol => 'OID_INET_SUB_OP', descr => 'is subnet',
oprname => '<<', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '>>(inet,inet)', oprcode => 'network_sub', oprrest => 'networksel',
oprjoin => 'networkjoinsel' },
{ oid => '932', oid_symbol => 'OID_INET_SUBEQ_OP',
descr => 'is subnet or equal',
oprname => '<<=', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '>>=(inet,inet)', oprcode => 'network_subeq',
oprrest => 'networksel', oprjoin => 'networkjoinsel' },
{ oid => '933', oid_symbol => 'OID_INET_SUP_OP', descr => 'is supernet',
oprname => '>>', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '<<(inet,inet)', oprcode => 'network_sup', oprrest => 'networksel',
oprjoin => 'networkjoinsel' },
{ oid => '934', oid_symbol => 'OID_INET_SUPEQ_OP',
descr => 'is supernet or equal',
oprname => '>>=', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '<<=(inet,inet)', oprcode => 'network_supeq',
oprrest => 'networksel', oprjoin => 'networkjoinsel' },
{ oid => '3552', oid_symbol => 'OID_INET_OVERLAP_OP',
descr => 'overlaps (is subnet or supernet)',
oprname => '&&', oprleft => 'inet', oprright => 'inet', oprresult => 'bool',
oprcom => '&&(inet,inet)', oprcode => 'network_overlap',
oprrest => 'networksel', oprjoin => 'networkjoinsel' },
{ oid => '2634', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'inet',
oprresult => 'inet', oprcode => 'inetnot' },
{ oid => '2635', descr => 'bitwise and',
oprname => '&', oprleft => 'inet', oprright => 'inet', oprresult => 'inet',
oprcode => 'inetand' },
{ oid => '2636', descr => 'bitwise or',
oprname => '|', oprleft => 'inet', oprright => 'inet', oprresult => 'inet',
oprcode => 'inetor' },
{ oid => '2637', descr => 'add',
oprname => '+', oprleft => 'inet', oprright => 'int8', oprresult => 'inet',
oprcom => '+(int8,inet)', oprcode => 'inetpl' },
{ oid => '2638', descr => 'add',
oprname => '+', oprleft => 'int8', oprright => 'inet', oprresult => 'inet',
oprcom => '+(inet,int8)', oprcode => 'int8pl_inet' },
{ oid => '2639', descr => 'subtract',
oprname => '-', oprleft => 'inet', oprright => 'int8', oprresult => 'inet',
oprcode => 'inetmi_int8' },
{ oid => '2640', descr => 'subtract',
oprname => '-', oprleft => 'inet', oprright => 'inet', oprresult => 'int8',
oprcode => 'inetmi' },
# case-insensitive LIKE hacks
{ oid => '1625', oid_symbol => 'OID_NAME_ICLIKE_OP',
descr => 'matches LIKE expression, case-insensitive',
oprname => '~~*', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '!~~*(name,text)', oprcode => 'nameiclike',
oprrest => 'iclikesel', oprjoin => 'iclikejoinsel' },
{ oid => '1626', descr => 'does not match LIKE expression, case-insensitive',
oprname => '!~~*', oprleft => 'name', oprright => 'text', oprresult => 'bool',
oprnegate => '~~*(name,text)', oprcode => 'nameicnlike',
oprrest => 'icnlikesel', oprjoin => 'icnlikejoinsel' },
{ oid => '1627', oid_symbol => 'OID_TEXT_ICLIKE_OP',
descr => 'matches LIKE expression, case-insensitive',
oprname => '~~*', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '!~~*(text,text)', oprcode => 'texticlike',
oprrest => 'iclikesel', oprjoin => 'iclikejoinsel' },
{ oid => '1628', descr => 'does not match LIKE expression, case-insensitive',
oprname => '!~~*', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprnegate => '~~*(text,text)', oprcode => 'texticnlike',
oprrest => 'icnlikesel', oprjoin => 'icnlikejoinsel' },
{ oid => '1629', oid_symbol => 'OID_BPCHAR_ICLIKE_OP',
descr => 'matches LIKE expression, case-insensitive',
oprname => '~~*', oprleft => 'bpchar', oprright => 'text',
oprresult => 'bool', oprnegate => '!~~*(bpchar,text)',
oprcode => 'bpchariclike', oprrest => 'iclikesel',
oprjoin => 'iclikejoinsel' },
{ oid => '1630', descr => 'does not match LIKE expression, case-insensitive',
oprname => '!~~*', oprleft => 'bpchar', oprright => 'text',
oprresult => 'bool', oprnegate => '~~*(bpchar,text)',
oprcode => 'bpcharicnlike', oprrest => 'icnlikesel',
oprjoin => 'icnlikejoinsel' },
# NUMERIC type - OID's 1700-1799
{ oid => '1751', descr => 'negate',
oprname => '-', oprkind => 'l', oprleft => '0', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_uminus' },
{ oid => '1752', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'numeric',
oprright => 'numeric', oprresult => 'bool', oprcom => '=(numeric,numeric)',
oprnegate => '<>(numeric,numeric)', oprcode => 'numeric_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1753', descr => 'not equal',
oprname => '<>', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'bool', oprcom => '<>(numeric,numeric)',
oprnegate => '=(numeric,numeric)', oprcode => 'numeric_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1754', descr => 'less than',
oprname => '<', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'bool', oprcom => '>(numeric,numeric)',
oprnegate => '>=(numeric,numeric)', oprcode => 'numeric_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1755', descr => 'less than or equal',
oprname => '<=', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'bool', oprcom => '>=(numeric,numeric)',
oprnegate => '>(numeric,numeric)', oprcode => 'numeric_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1756', descr => 'greater than',
oprname => '>', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'bool', oprcom => '<(numeric,numeric)',
oprnegate => '<=(numeric,numeric)', oprcode => 'numeric_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1757', descr => 'greater than or equal',
oprname => '>=', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'bool', oprcom => '<=(numeric,numeric)',
oprnegate => '<(numeric,numeric)', oprcode => 'numeric_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1758', descr => 'add',
oprname => '+', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcom => '+(numeric,numeric)',
oprcode => 'numeric_add' },
{ oid => '1759', descr => 'subtract',
oprname => '-', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_sub' },
{ oid => '1760', descr => 'multiply',
oprname => '*', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcom => '*(numeric,numeric)',
oprcode => 'numeric_mul' },
{ oid => '1761', descr => 'divide',
oprname => '/', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_div' },
{ oid => '1762', descr => 'modulus',
oprname => '%', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_mod' },
{ oid => '1038', descr => 'exponentiation',
oprname => '^', oprleft => 'numeric', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_power' },
{ oid => '1763', descr => 'absolute value',
oprname => '@', oprkind => 'l', oprleft => '0', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_abs' },
{ oid => '1784', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'bit', oprright => 'bit',
oprresult => 'bool', oprcom => '=(bit,bit)', oprnegate => '<>(bit,bit)',
oprcode => 'biteq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '1785', descr => 'not equal',
oprname => '<>', oprleft => 'bit', oprright => 'bit', oprresult => 'bool',
oprcom => '<>(bit,bit)', oprnegate => '=(bit,bit)', oprcode => 'bitne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1786', descr => 'less than',
oprname => '<', oprleft => 'bit', oprright => 'bit', oprresult => 'bool',
oprcom => '>(bit,bit)', oprnegate => '>=(bit,bit)', oprcode => 'bitlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1787', descr => 'greater than',
oprname => '>', oprleft => 'bit', oprright => 'bit', oprresult => 'bool',
oprcom => '<(bit,bit)', oprnegate => '<=(bit,bit)', oprcode => 'bitgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1788', descr => 'less than or equal',
oprname => '<=', oprleft => 'bit', oprright => 'bit', oprresult => 'bool',
oprcom => '>=(bit,bit)', oprnegate => '>(bit,bit)', oprcode => 'bitle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1789', descr => 'greater than or equal',
oprname => '>=', oprleft => 'bit', oprright => 'bit', oprresult => 'bool',
oprcom => '<=(bit,bit)', oprnegate => '<(bit,bit)', oprcode => 'bitge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1791', descr => 'bitwise and',
oprname => '&', oprleft => 'bit', oprright => 'bit', oprresult => 'bit',
oprcom => '&(bit,bit)', oprcode => 'bitand' },
{ oid => '1792', descr => 'bitwise or',
oprname => '|', oprleft => 'bit', oprright => 'bit', oprresult => 'bit',
oprcom => '|(bit,bit)', oprcode => 'bitor' },
{ oid => '1793', descr => 'bitwise exclusive or',
oprname => '#', oprleft => 'bit', oprright => 'bit', oprresult => 'bit',
oprcom => '#(bit,bit)', oprcode => 'bitxor' },
{ oid => '1794', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'bit',
oprresult => 'bit', oprcode => 'bitnot' },
{ oid => '1795', descr => 'bitwise shift left',
oprname => '<<', oprleft => 'bit', oprright => 'int4', oprresult => 'bit',
oprcode => 'bitshiftleft' },
{ oid => '1796', descr => 'bitwise shift right',
oprname => '>>', oprleft => 'bit', oprright => 'int4', oprresult => 'bit',
oprcode => 'bitshiftright' },
{ oid => '1797', descr => 'concatenate',
oprname => '||', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'varbit', oprcode => 'bitcat' },
{ oid => '1800', descr => 'add',
oprname => '+', oprleft => 'time', oprright => 'interval',
oprresult => 'time', oprcom => '+(interval,time)',
oprcode => 'time_pl_interval' },
{ oid => '1801', descr => 'subtract',
oprname => '-', oprleft => 'time', oprright => 'interval',
oprresult => 'time', oprcode => 'time_mi_interval' },
{ oid => '1802', descr => 'add',
oprname => '+', oprleft => 'timetz', oprright => 'interval',
oprresult => 'timetz', oprcom => '+(interval,timetz)',
oprcode => 'timetz_pl_interval' },
{ oid => '1803', descr => 'subtract',
oprname => '-', oprleft => 'timetz', oprright => 'interval',
oprresult => 'timetz', oprcode => 'timetz_mi_interval' },
{ oid => '1804', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '=(varbit,varbit)',
oprnegate => '<>(varbit,varbit)', oprcode => 'varbiteq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1805', descr => 'not equal',
oprname => '<>', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '<>(varbit,varbit)',
oprnegate => '=(varbit,varbit)', oprcode => 'varbitne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '1806', descr => 'less than',
oprname => '<', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '>(varbit,varbit)',
oprnegate => '>=(varbit,varbit)', oprcode => 'varbitlt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1807', descr => 'greater than',
oprname => '>', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '<(varbit,varbit)',
oprnegate => '<=(varbit,varbit)', oprcode => 'varbitgt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1808', descr => 'less than or equal',
oprname => '<=', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '>=(varbit,varbit)',
oprnegate => '>(varbit,varbit)', oprcode => 'varbitle',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1809', descr => 'greater than or equal',
oprname => '>=', oprleft => 'varbit', oprright => 'varbit',
oprresult => 'bool', oprcom => '<=(varbit,varbit)',
oprnegate => '<(varbit,varbit)', oprcode => 'varbitge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1849', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'time',
oprresult => 'time', oprcom => '+(time,interval)',
oprcode => 'interval_pl_time' },
{ oid => '1862', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int2',
oprright => 'int8', oprresult => 'bool', oprcom => '=(int8,int2)',
oprnegate => '<>(int2,int8)', oprcode => 'int28eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1863', descr => 'not equal',
oprname => '<>', oprleft => 'int2', oprright => 'int8', oprresult => 'bool',
oprcom => '<>(int8,int2)', oprnegate => '=(int2,int8)', oprcode => 'int28ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1864', descr => 'less than',
oprname => '<', oprleft => 'int2', oprright => 'int8', oprresult => 'bool',
oprcom => '>(int8,int2)', oprnegate => '>=(int2,int8)', oprcode => 'int28lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1865', descr => 'greater than',
oprname => '>', oprleft => 'int2', oprright => 'int8', oprresult => 'bool',
oprcom => '<(int8,int2)', oprnegate => '<=(int2,int8)', oprcode => 'int28gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1866', descr => 'less than or equal',
oprname => '<=', oprleft => 'int2', oprright => 'int8', oprresult => 'bool',
oprcom => '>=(int8,int2)', oprnegate => '>(int2,int8)', oprcode => 'int28le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1867', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int2', oprright => 'int8', oprresult => 'bool',
oprcom => '<=(int8,int2)', oprnegate => '<(int2,int8)', oprcode => 'int28ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1868', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'int8',
oprright => 'int2', oprresult => 'bool', oprcom => '=(int2,int8)',
oprnegate => '<>(int8,int2)', oprcode => 'int82eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1869', descr => 'not equal',
oprname => '<>', oprleft => 'int8', oprright => 'int2', oprresult => 'bool',
oprcom => '<>(int2,int8)', oprnegate => '=(int8,int2)', oprcode => 'int82ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '1870', descr => 'less than',
oprname => '<', oprleft => 'int8', oprright => 'int2', oprresult => 'bool',
oprcom => '>(int2,int8)', oprnegate => '>=(int8,int2)', oprcode => 'int82lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '1871', descr => 'greater than',
oprname => '>', oprleft => 'int8', oprright => 'int2', oprresult => 'bool',
oprcom => '<(int2,int8)', oprnegate => '<=(int8,int2)', oprcode => 'int82gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '1872', descr => 'less than or equal',
oprname => '<=', oprleft => 'int8', oprright => 'int2', oprresult => 'bool',
oprcom => '>=(int2,int8)', oprnegate => '>(int8,int2)', oprcode => 'int82le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '1873', descr => 'greater than or equal',
oprname => '>=', oprleft => 'int8', oprright => 'int2', oprresult => 'bool',
oprcom => '<=(int2,int8)', oprnegate => '<(int8,int2)', oprcode => 'int82ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '1874', descr => 'bitwise and',
oprname => '&', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcom => '&(int2,int2)', oprcode => 'int2and' },
{ oid => '1875', descr => 'bitwise or',
oprname => '|', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcom => '|(int2,int2)', oprcode => 'int2or' },
{ oid => '1876', descr => 'bitwise exclusive or',
oprname => '#', oprleft => 'int2', oprright => 'int2', oprresult => 'int2',
oprcom => '#(int2,int2)', oprcode => 'int2xor' },
{ oid => '1877', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'int2',
oprresult => 'int2', oprcode => 'int2not' },
{ oid => '1878', descr => 'bitwise shift left',
oprname => '<<', oprleft => 'int2', oprright => 'int4', oprresult => 'int2',
oprcode => 'int2shl' },
{ oid => '1879', descr => 'bitwise shift right',
oprname => '>>', oprleft => 'int2', oprright => 'int4', oprresult => 'int2',
oprcode => 'int2shr' },
{ oid => '1880', descr => 'bitwise and',
oprname => '&', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcom => '&(int4,int4)', oprcode => 'int4and' },
{ oid => '1881', descr => 'bitwise or',
oprname => '|', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcom => '|(int4,int4)', oprcode => 'int4or' },
{ oid => '1882', descr => 'bitwise exclusive or',
oprname => '#', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcom => '#(int4,int4)', oprcode => 'int4xor' },
{ oid => '1883', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'int4',
oprresult => 'int4', oprcode => 'int4not' },
{ oid => '1884', descr => 'bitwise shift left',
oprname => '<<', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcode => 'int4shl' },
{ oid => '1885', descr => 'bitwise shift right',
oprname => '>>', oprleft => 'int4', oprright => 'int4', oprresult => 'int4',
oprcode => 'int4shr' },
{ oid => '1886', descr => 'bitwise and',
oprname => '&', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcom => '&(int8,int8)', oprcode => 'int8and' },
{ oid => '1887', descr => 'bitwise or',
oprname => '|', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcom => '|(int8,int8)', oprcode => 'int8or' },
{ oid => '1888', descr => 'bitwise exclusive or',
oprname => '#', oprleft => 'int8', oprright => 'int8', oprresult => 'int8',
oprcom => '#(int8,int8)', oprcode => 'int8xor' },
{ oid => '1889', descr => 'bitwise not',
oprname => '~', oprkind => 'l', oprleft => '0', oprright => 'int8',
oprresult => 'int8', oprcode => 'int8not' },
{ oid => '1890', descr => 'bitwise shift left',
oprname => '<<', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcode => 'int8shl' },
{ oid => '1891', descr => 'bitwise shift right',
oprname => '>>', oprleft => 'int8', oprright => 'int4', oprresult => 'int8',
oprcode => 'int8shr' },
{ oid => '1916', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'int8',
oprresult => 'int8', oprcode => 'int8up' },
{ oid => '1917', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'int2',
oprresult => 'int2', oprcode => 'int2up' },
{ oid => '1918', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'int4',
oprresult => 'int4', oprcode => 'int4up' },
{ oid => '1919', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'float4',
oprresult => 'float4', oprcode => 'float4up' },
{ oid => '1920', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'float8',
oprresult => 'float8', oprcode => 'float8up' },
{ oid => '1921', descr => 'unary plus',
oprname => '+', oprkind => 'l', oprleft => '0', oprright => 'numeric',
oprresult => 'numeric', oprcode => 'numeric_uplus' },
# bytea operators
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1955', oid_symbol => 'ByteaEqualOperator', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'bytea',
oprright => 'bytea', oprresult => 'bool', oprcom => '=(bytea,bytea)',
oprnegate => '<>(bytea,bytea)', oprcode => 'byteaeq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '1956', descr => 'not equal',
oprname => '<>', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprcom => '<>(bytea,bytea)', oprnegate => '=(bytea,bytea)',
oprcode => 'byteane', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1957', oid_symbol => 'ByteaLessOperator', descr => 'less than',
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
oprname => '<', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprcom => '>(bytea,bytea)', oprnegate => '>=(bytea,bytea)',
oprcode => 'bytealt', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '1958', descr => 'less than or equal',
oprname => '<=', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprcom => '>=(bytea,bytea)', oprnegate => '>(bytea,bytea)',
oprcode => 'byteale', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '1959', descr => 'greater than',
oprname => '>', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprcom => '<(bytea,bytea)', oprnegate => '<=(bytea,bytea)',
oprcode => 'byteagt', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '1960', oid_symbol => 'ByteaGreaterEqualOperator',
descr => 'greater than or equal',
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
oprname => '>=', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprcom => '<=(bytea,bytea)', oprnegate => '<(bytea,bytea)',
oprcode => 'byteage', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '2016', oid_symbol => 'OID_BYTEA_LIKE_OP',
descr => 'matches LIKE expression',
oprname => '~~', oprleft => 'bytea', oprright => 'bytea', oprresult => 'bool',
oprnegate => '!~~(bytea,bytea)', oprcode => 'bytealike', oprrest => 'likesel',
oprjoin => 'likejoinsel' },
{ oid => '2017', descr => 'does not match LIKE expression',
oprname => '!~~', oprleft => 'bytea', oprright => 'bytea',
oprresult => 'bool', oprnegate => '~~(bytea,bytea)', oprcode => 'byteanlike',
oprrest => 'nlikesel', oprjoin => 'nlikejoinsel' },
{ oid => '2018', descr => 'concatenate',
oprname => '||', oprleft => 'bytea', oprright => 'bytea',
oprresult => 'bytea', oprcode => 'byteacat' },
# timestamp operators
{ oid => '2060', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'timestamp',
oprright => 'timestamp', oprresult => 'bool',
oprcom => '=(timestamp,timestamp)', oprnegate => '<>(timestamp,timestamp)',
oprcode => 'timestamp_eq', oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '2061', descr => 'not equal',
oprname => '<>', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<>(timestamp,timestamp)',
oprnegate => '=(timestamp,timestamp)', oprcode => 'timestamp_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2062', descr => 'less than',
oprname => '<', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>(timestamp,timestamp)',
oprnegate => '>=(timestamp,timestamp)', oprcode => 'timestamp_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2063', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>=(timestamp,timestamp)',
oprnegate => '>(timestamp,timestamp)', oprcode => 'timestamp_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2064', descr => 'greater than',
oprname => '>', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<(timestamp,timestamp)',
oprnegate => '<=(timestamp,timestamp)', oprcode => 'timestamp_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2065', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<=(timestamp,timestamp)',
oprnegate => '<(timestamp,timestamp)', oprcode => 'timestamp_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2066', descr => 'add',
oprname => '+', oprleft => 'timestamp', oprright => 'interval',
oprresult => 'timestamp', oprcom => '+(interval,timestamp)',
oprcode => 'timestamp_pl_interval' },
{ oid => '2067', descr => 'subtract',
oprname => '-', oprleft => 'timestamp', oprright => 'timestamp',
oprresult => 'interval', oprcode => 'timestamp_mi' },
{ oid => '2068', descr => 'subtract',
oprname => '-', oprleft => 'timestamp', oprright => 'interval',
oprresult => 'timestamp', oprcode => 'timestamp_mi_interval' },
# character-by-character (not collation order) comparison operators for character types
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '2314', oid_symbol => 'TextPatternLessOperator',
descr => 'less than',
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
oprname => '~<~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '~>~(text,text)', oprnegate => '~>=~(text,text)',
oprcode => 'text_pattern_lt', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '2315', descr => 'less than or equal',
oprname => '~<=~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '~>=~(text,text)', oprnegate => '~>~(text,text)',
oprcode => 'text_pattern_le', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '2317', oid_symbol => 'TextPatternGreaterEqualOperator',
descr => 'greater than or equal',
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
oprname => '~>=~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '~<=~(text,text)', oprnegate => '~<~(text,text)',
oprcode => 'text_pattern_ge', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '2318', descr => 'greater than',
oprname => '~>~', oprleft => 'text', oprright => 'text', oprresult => 'bool',
oprcom => '~<~(text,text)', oprnegate => '~<=~(text,text)',
oprcode => 'text_pattern_gt', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '2326', oid_symbol => 'BpcharPatternLessOperator',
descr => 'less than',
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
oprname => '~<~', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '~>~(bpchar,bpchar)',
oprnegate => '~>=~(bpchar,bpchar)', oprcode => 'bpchar_pattern_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2327', descr => 'less than or equal',
oprname => '~<=~', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '~>=~(bpchar,bpchar)',
oprnegate => '~>~(bpchar,bpchar)', oprcode => 'bpchar_pattern_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
Reduce match_pattern_prefix()'s dependencies on index opfamilies. Historically, the planner's LIKE/regex index optimizations were only carried out for specific index opfamilies. That's never been a great idea from the standpoint of extensibility, but it didn't matter so much as long as we had no practical way to extend such behaviors anyway. With the addition of planner support functions, and in view of ongoing work to support additional table and index AMs, it seems like a good time to relax this. Hence, recast the decisions in match_pattern_prefix() so that rather than decide which operators to generate by looking at what the index opfamily contains, we decide which operators to generate a-priori and then see if the opfamily supports them. This is much more defensible from a semantic standpoint anyway, since we know the semantics of the chosen operators precisely, and we only need to assume that the opfamily correctly implements operators it claims to support. The existing "pattern" opfamilies put a crimp in this approach, since we need to select the pattern operators if we want those to work. So we still have to special-case those opfamilies. But that seems all right, since in view of the addition of collations, the pattern opfamilies seem like a legacy hack that nobody will be building on. The only immediate effect of this change, so far as the core code is concerned, is that anchored LIKE/regex patterns can be mapped onto BRIN index searches, and exact-match patterns can be mapped onto hash indexes, not only btree and spgist indexes as before. That's not a terribly exciting result, but it does fix an omission mentioned in the ancient comments here. Note: no catversion bump, even though this touches pg_operator.dat, because it's only adding OID macros not changing the contents of postgres.bki. Per consideration of a report from Manuel Rigger. Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
2019-11-20 20:13:04 +01:00
{ oid => '2329', oid_symbol => 'BpcharPatternGreaterEqualOperator',
descr => 'greater than or equal',
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
oprname => '~>=~', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '~<=~(bpchar,bpchar)',
oprnegate => '~<~(bpchar,bpchar)', oprcode => 'bpchar_pattern_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2330', descr => 'greater than',
oprname => '~>~', oprleft => 'bpchar', oprright => 'bpchar',
oprresult => 'bool', oprcom => '~<~(bpchar,bpchar)',
oprnegate => '~<=~(bpchar,bpchar)', oprcode => 'bpchar_pattern_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
# crosstype operations for date vs. timestamp and timestamptz
{ oid => '2345', descr => 'less than',
oprname => '<', oprleft => 'date', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>(timestamp,date)',
oprnegate => '>=(date,timestamp)', oprcode => 'date_lt_timestamp',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2346', descr => 'less than or equal',
oprname => '<=', oprleft => 'date', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>=(timestamp,date)',
oprnegate => '>(date,timestamp)', oprcode => 'date_le_timestamp',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2347', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'date',
oprright => 'timestamp', oprresult => 'bool', oprcom => '=(timestamp,date)',
oprnegate => '<>(date,timestamp)', oprcode => 'date_eq_timestamp',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '2348', descr => 'greater than or equal',
oprname => '>=', oprleft => 'date', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<=(timestamp,date)',
oprnegate => '<(date,timestamp)', oprcode => 'date_ge_timestamp',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2349', descr => 'greater than',
oprname => '>', oprleft => 'date', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<(timestamp,date)',
oprnegate => '<=(date,timestamp)', oprcode => 'date_gt_timestamp',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2350', descr => 'not equal',
oprname => '<>', oprleft => 'date', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<>(timestamp,date)',
oprnegate => '=(date,timestamp)', oprcode => 'date_ne_timestamp',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2358', descr => 'less than',
oprname => '<', oprleft => 'date', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>(timestamptz,date)',
oprnegate => '>=(date,timestamptz)', oprcode => 'date_lt_timestamptz',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2359', descr => 'less than or equal',
oprname => '<=', oprleft => 'date', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>=(timestamptz,date)',
oprnegate => '>(date,timestamptz)', oprcode => 'date_le_timestamptz',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2360', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'date',
oprright => 'timestamptz', oprresult => 'bool',
oprcom => '=(timestamptz,date)', oprnegate => '<>(date,timestamptz)',
oprcode => 'date_eq_timestamptz', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '2361', descr => 'greater than or equal',
oprname => '>=', oprleft => 'date', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<=(timestamptz,date)',
oprnegate => '<(date,timestamptz)', oprcode => 'date_ge_timestamptz',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2362', descr => 'greater than',
oprname => '>', oprleft => 'date', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<(timestamptz,date)',
oprnegate => '<=(date,timestamptz)', oprcode => 'date_gt_timestamptz',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2363', descr => 'not equal',
oprname => '<>', oprleft => 'date', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<>(timestamptz,date)',
oprnegate => '=(date,timestamptz)', oprcode => 'date_ne_timestamptz',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2371', descr => 'less than',
oprname => '<', oprleft => 'timestamp', oprright => 'date',
oprresult => 'bool', oprcom => '>(date,timestamp)',
oprnegate => '>=(timestamp,date)', oprcode => 'timestamp_lt_date',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2372', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamp', oprright => 'date',
oprresult => 'bool', oprcom => '>=(date,timestamp)',
oprnegate => '>(timestamp,date)', oprcode => 'timestamp_le_date',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2373', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'timestamp',
oprright => 'date', oprresult => 'bool', oprcom => '=(date,timestamp)',
oprnegate => '<>(timestamp,date)', oprcode => 'timestamp_eq_date',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '2374', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamp', oprright => 'date',
oprresult => 'bool', oprcom => '<=(date,timestamp)',
oprnegate => '<(timestamp,date)', oprcode => 'timestamp_ge_date',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2375', descr => 'greater than',
oprname => '>', oprleft => 'timestamp', oprright => 'date',
oprresult => 'bool', oprcom => '<(date,timestamp)',
oprnegate => '<=(timestamp,date)', oprcode => 'timestamp_gt_date',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2376', descr => 'not equal',
oprname => '<>', oprleft => 'timestamp', oprright => 'date',
oprresult => 'bool', oprcom => '<>(date,timestamp)',
oprnegate => '=(timestamp,date)', oprcode => 'timestamp_ne_date',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2384', descr => 'less than',
oprname => '<', oprleft => 'timestamptz', oprright => 'date',
oprresult => 'bool', oprcom => '>(date,timestamptz)',
oprnegate => '>=(timestamptz,date)', oprcode => 'timestamptz_lt_date',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2385', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamptz', oprright => 'date',
oprresult => 'bool', oprcom => '>=(date,timestamptz)',
oprnegate => '>(timestamptz,date)', oprcode => 'timestamptz_le_date',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2386', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'timestamptz',
oprright => 'date', oprresult => 'bool', oprcom => '=(date,timestamptz)',
oprnegate => '<>(timestamptz,date)', oprcode => 'timestamptz_eq_date',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '2387', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamptz', oprright => 'date',
oprresult => 'bool', oprcom => '<=(date,timestamptz)',
oprnegate => '<(timestamptz,date)', oprcode => 'timestamptz_ge_date',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '2388', descr => 'greater than',
oprname => '>', oprleft => 'timestamptz', oprright => 'date',
oprresult => 'bool', oprcom => '<(date,timestamptz)',
oprnegate => '<=(timestamptz,date)', oprcode => 'timestamptz_gt_date',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2389', descr => 'not equal',
oprname => '<>', oprleft => 'timestamptz', oprright => 'date',
oprresult => 'bool', oprcom => '<>(date,timestamptz)',
oprnegate => '=(timestamptz,date)', oprcode => 'timestamptz_ne_date',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
# crosstype operations for timestamp vs. timestamptz
{ oid => '2534', descr => 'less than',
oprname => '<', oprleft => 'timestamp', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>(timestamptz,timestamp)',
oprnegate => '>=(timestamp,timestamptz)',
oprcode => 'timestamp_lt_timestamptz', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '2535', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamp', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '>=(timestamptz,timestamp)',
oprnegate => '>(timestamp,timestamptz)',
oprcode => 'timestamp_le_timestamptz', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '2536', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'timestamp',
oprright => 'timestamptz', oprresult => 'bool',
oprcom => '=(timestamptz,timestamp)',
oprnegate => '<>(timestamp,timestamptz)',
oprcode => 'timestamp_eq_timestamptz', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '2537', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamp', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<=(timestamptz,timestamp)',
oprnegate => '<(timestamp,timestamptz)',
oprcode => 'timestamp_ge_timestamptz', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '2538', descr => 'greater than',
oprname => '>', oprleft => 'timestamp', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<(timestamptz,timestamp)',
oprnegate => '<=(timestamp,timestamptz)',
oprcode => 'timestamp_gt_timestamptz', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '2539', descr => 'not equal',
oprname => '<>', oprleft => 'timestamp', oprright => 'timestamptz',
oprresult => 'bool', oprcom => '<>(timestamptz,timestamp)',
oprnegate => '=(timestamp,timestamptz)',
oprcode => 'timestamp_ne_timestamptz', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '2540', descr => 'less than',
oprname => '<', oprleft => 'timestamptz', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>(timestamp,timestamptz)',
oprnegate => '>=(timestamptz,timestamp)',
oprcode => 'timestamptz_lt_timestamp', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '2541', descr => 'less than or equal',
oprname => '<=', oprleft => 'timestamptz', oprright => 'timestamp',
oprresult => 'bool', oprcom => '>=(timestamp,timestamptz)',
oprnegate => '>(timestamptz,timestamp)',
oprcode => 'timestamptz_le_timestamp', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '2542', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'timestamptz',
oprright => 'timestamp', oprresult => 'bool',
oprcom => '=(timestamp,timestamptz)',
oprnegate => '<>(timestamptz,timestamp)',
oprcode => 'timestamptz_eq_timestamp', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '2543', descr => 'greater than or equal',
oprname => '>=', oprleft => 'timestamptz', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<=(timestamp,timestamptz)',
oprnegate => '<(timestamptz,timestamp)',
oprcode => 'timestamptz_ge_timestamp', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '2544', descr => 'greater than',
oprname => '>', oprleft => 'timestamptz', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<(timestamp,timestamptz)',
oprnegate => '<=(timestamptz,timestamp)',
oprcode => 'timestamptz_gt_timestamp', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '2545', descr => 'not equal',
oprname => '<>', oprleft => 'timestamptz', oprright => 'timestamp',
oprresult => 'bool', oprcom => '<>(timestamp,timestamptz)',
oprnegate => '=(timestamptz,timestamp)',
oprcode => 'timestamptz_ne_timestamp', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
# formerly-missing interval + datetime operators
{ oid => '2551', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'date',
oprresult => 'timestamp', oprcom => '+(date,interval)',
oprcode => 'interval_pl_date' },
{ oid => '2552', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'timetz',
oprresult => 'timetz', oprcom => '+(timetz,interval)',
oprcode => 'interval_pl_timetz' },
{ oid => '2553', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'timestamp',
oprresult => 'timestamp', oprcom => '+(timestamp,interval)',
oprcode => 'interval_pl_timestamp' },
{ oid => '2554', descr => 'add',
oprname => '+', oprleft => 'interval', oprright => 'timestamptz',
oprresult => 'timestamptz', oprcom => '+(timestamptz,interval)',
oprcode => 'interval_pl_timestamptz' },
{ oid => '2555', descr => 'add',
oprname => '+', oprleft => 'int4', oprright => 'date', oprresult => 'date',
oprcom => '+(date,int4)', oprcode => 'integer_pl_date' },
# new operators for Y-direction rtree opfamilies
{ oid => '2570', descr => 'is below',
oprname => '<<|', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_below', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2571', descr => 'overlaps or is below',
oprname => '&<|', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_overbelow', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2572', descr => 'overlaps or is above',
oprname => '|&>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_overabove', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2573', descr => 'is above',
oprname => '|>>', oprleft => 'box', oprright => 'box', oprresult => 'bool',
oprcode => 'box_above', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2574', descr => 'is below',
oprname => '<<|', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_below', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2575', descr => 'overlaps or is below',
oprname => '&<|', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_overbelow', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2576', descr => 'overlaps or is above',
oprname => '|&>', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_overabove', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2577', descr => 'is above',
oprname => '|>>', oprleft => 'polygon', oprright => 'polygon',
oprresult => 'bool', oprcode => 'poly_above', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2589', descr => 'overlaps or is below',
oprname => '&<|', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_overbelow', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
{ oid => '2590', descr => 'overlaps or is above',
oprname => '|&>', oprleft => 'circle', oprright => 'circle',
oprresult => 'bool', oprcode => 'circle_overabove', oprrest => 'positionsel',
oprjoin => 'positionjoinsel' },
# overlap/contains/contained for arrays
{ oid => '2750', oid_symbol => 'OID_ARRAY_OVERLAP_OP', descr => 'overlaps',
oprname => '&&', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '&&(anyarray,anyarray)',
oprcode => 'arrayoverlap', oprrest => 'arraycontsel',
oprjoin => 'arraycontjoinsel' },
{ oid => '2751', oid_symbol => 'OID_ARRAY_CONTAINS_OP', descr => 'contains',
oprname => '@>', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '<@(anyarray,anyarray)',
oprcode => 'arraycontains', oprrest => 'arraycontsel',
oprjoin => 'arraycontjoinsel' },
{ oid => '2752', oid_symbol => 'OID_ARRAY_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anyarray', oprright => 'anyarray',
oprresult => 'bool', oprcom => '@>(anyarray,anyarray)',
oprcode => 'arraycontained', oprrest => 'arraycontsel',
oprjoin => 'arraycontjoinsel' },
# capturing operators to preserve pre-8.3 behavior of text concatenation
{ oid => '2779', descr => 'concatenate',
oprname => '||', oprleft => 'text', oprright => 'anynonarray',
oprresult => 'text', oprcode => 'textanycat' },
{ oid => '2780', descr => 'concatenate',
oprname => '||', oprleft => 'anynonarray', oprright => 'text',
oprresult => 'text', oprcode => 'anytextcat' },
# uuid operators
{ oid => '2972', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'uuid',
oprright => 'uuid', oprresult => 'bool', oprcom => '=(uuid,uuid)',
oprnegate => '<>(uuid,uuid)', oprcode => 'uuid_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '2973', descr => 'not equal',
oprname => '<>', oprleft => 'uuid', oprright => 'uuid', oprresult => 'bool',
oprcom => '<>(uuid,uuid)', oprnegate => '=(uuid,uuid)', oprcode => 'uuid_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2974', descr => 'less than',
oprname => '<', oprleft => 'uuid', oprright => 'uuid', oprresult => 'bool',
oprcom => '>(uuid,uuid)', oprnegate => '>=(uuid,uuid)', oprcode => 'uuid_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2975', descr => 'greater than',
oprname => '>', oprleft => 'uuid', oprright => 'uuid', oprresult => 'bool',
oprcom => '<(uuid,uuid)', oprnegate => '<=(uuid,uuid)', oprcode => 'uuid_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2976', descr => 'less than or equal',
oprname => '<=', oprleft => 'uuid', oprright => 'uuid', oprresult => 'bool',
oprcom => '>=(uuid,uuid)', oprnegate => '>(uuid,uuid)', oprcode => 'uuid_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2977', descr => 'greater than or equal',
oprname => '>=', oprleft => 'uuid', oprright => 'uuid', oprresult => 'bool',
oprcom => '<=(uuid,uuid)', oprnegate => '<(uuid,uuid)', oprcode => 'uuid_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# pg_lsn operators
{ oid => '3222', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'pg_lsn',
oprright => 'pg_lsn', oprresult => 'bool', oprcom => '=(pg_lsn,pg_lsn)',
oprnegate => '<>(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '3223', descr => 'not equal',
oprname => '<>', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'bool', oprcom => '<>(pg_lsn,pg_lsn)',
oprnegate => '=(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '3224', descr => 'less than',
oprname => '<', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'bool', oprcom => '>(pg_lsn,pg_lsn)',
oprnegate => '>=(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3225', descr => 'greater than',
oprname => '>', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'bool', oprcom => '<(pg_lsn,pg_lsn)',
oprnegate => '<=(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3226', descr => 'less than or equal',
oprname => '<=', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'bool', oprcom => '>=(pg_lsn,pg_lsn)',
oprnegate => '>(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3227', descr => 'greater than or equal',
oprname => '>=', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'bool', oprcom => '<=(pg_lsn,pg_lsn)',
oprnegate => '<(pg_lsn,pg_lsn)', oprcode => 'pg_lsn_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '3228', descr => 'minus',
oprname => '-', oprleft => 'pg_lsn', oprright => 'pg_lsn',
oprresult => 'numeric', oprcode => 'pg_lsn_mi' },
Add +(pg_lsn,numeric) and -(pg_lsn,numeric) operators. By using these operators, the number of bytes can be added into and subtracted from LSN. Bump catalog version. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Asif Rehman Discussion: https://postgr.es/m/ed9f7f74-e996-67f8-554a-52ebd3779b3b@oss.nttdata.com
2020-06-30 16:55:07 +02:00
{ oid => '5025', descr => 'add',
oprname => '+', oprleft => 'pg_lsn', oprright => 'numeric',
oprresult => 'pg_lsn', oprcom => '+(numeric,pg_lsn)',
oprcode => 'pg_lsn_pli' },
{ oid => '5026', descr => 'add',
oprname => '+', oprleft => 'numeric', oprright => 'pg_lsn',
oprresult => 'pg_lsn', oprcom => '+(pg_lsn,numeric)',
oprcode => 'numeric_pl_pg_lsn' },
{ oid => '5027', descr => 'subtract',
oprname => '-', oprleft => 'pg_lsn', oprright => 'numeric',
oprresult => 'pg_lsn', oprcode => 'pg_lsn_mii' },
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
# enum operators
{ oid => '3516', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'anyenum',
oprright => 'anyenum', oprresult => 'bool', oprcom => '=(anyenum,anyenum)',
oprnegate => '<>(anyenum,anyenum)', oprcode => 'enum_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '3517', descr => 'not equal',
oprname => '<>', oprleft => 'anyenum', oprright => 'anyenum',
oprresult => 'bool', oprcom => '<>(anyenum,anyenum)',
oprnegate => '=(anyenum,anyenum)', oprcode => 'enum_ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '3518', descr => 'less than',
oprname => '<', oprleft => 'anyenum', oprright => 'anyenum',
oprresult => 'bool', oprcom => '>(anyenum,anyenum)',
oprnegate => '>=(anyenum,anyenum)', oprcode => 'enum_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3519', descr => 'greater than',
oprname => '>', oprleft => 'anyenum', oprright => 'anyenum',
oprresult => 'bool', oprcom => '<(anyenum,anyenum)',
oprnegate => '<=(anyenum,anyenum)', oprcode => 'enum_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3520', descr => 'less than or equal',
oprname => '<=', oprleft => 'anyenum', oprright => 'anyenum',
oprresult => 'bool', oprcom => '>=(anyenum,anyenum)',
oprnegate => '>(anyenum,anyenum)', oprcode => 'enum_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3521', descr => 'greater than or equal',
oprname => '>=', oprleft => 'anyenum', oprright => 'anyenum',
oprresult => 'bool', oprcom => '<=(anyenum,anyenum)',
oprnegate => '<(anyenum,anyenum)', oprcode => 'enum_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# tsearch operations
{ oid => '3627', descr => 'less than',
oprname => '<', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'bool', oprcom => '>(tsvector,tsvector)',
oprnegate => '>=(tsvector,tsvector)', oprcode => 'tsvector_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3628', descr => 'less than or equal',
oprname => '<=', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'bool', oprcom => '>=(tsvector,tsvector)',
oprnegate => '>(tsvector,tsvector)', oprcode => 'tsvector_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3629', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'tsvector',
oprright => 'tsvector', oprresult => 'bool', oprcom => '=(tsvector,tsvector)',
oprnegate => '<>(tsvector,tsvector)', oprcode => 'tsvector_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '3630', descr => 'not equal',
oprname => '<>', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'bool', oprcom => '<>(tsvector,tsvector)',
oprnegate => '=(tsvector,tsvector)', oprcode => 'tsvector_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3631', descr => 'greater than or equal',
oprname => '>=', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'bool', oprcom => '<=(tsvector,tsvector)',
oprnegate => '<(tsvector,tsvector)', oprcode => 'tsvector_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '3632', descr => 'greater than',
oprname => '>', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'bool', oprcom => '<(tsvector,tsvector)',
oprnegate => '<=(tsvector,tsvector)', oprcode => 'tsvector_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3633', descr => 'concatenate',
oprname => '||', oprleft => 'tsvector', oprright => 'tsvector',
oprresult => 'tsvector', oprcode => 'tsvector_concat' },
{ oid => '3636', descr => 'text search match',
oprname => '@@', oprleft => 'tsvector', oprright => 'tsquery',
oprresult => 'bool', oprcom => '@@(tsquery,tsvector)',
oprcode => 'ts_match_vq', oprrest => 'tsmatchsel',
oprjoin => 'tsmatchjoinsel' },
{ oid => '3637', descr => 'text search match',
oprname => '@@', oprleft => 'tsquery', oprright => 'tsvector',
oprresult => 'bool', oprcom => '@@(tsvector,tsquery)',
oprcode => 'ts_match_qv', oprrest => 'tsmatchsel',
oprjoin => 'tsmatchjoinsel' },
{ oid => '3660', descr => 'deprecated, use @@ instead',
oprname => '@@@', oprleft => 'tsvector', oprright => 'tsquery',
oprresult => 'bool', oprcom => '@@@(tsquery,tsvector)',
oprcode => 'ts_match_vq', oprrest => 'tsmatchsel',
oprjoin => 'tsmatchjoinsel' },
{ oid => '3661', descr => 'deprecated, use @@ instead',
oprname => '@@@', oprleft => 'tsquery', oprright => 'tsvector',
oprresult => 'bool', oprcom => '@@@(tsvector,tsquery)',
oprcode => 'ts_match_qv', oprrest => 'tsmatchsel',
oprjoin => 'tsmatchjoinsel' },
{ oid => '3674', descr => 'less than',
oprname => '<', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '>(tsquery,tsquery)',
oprnegate => '>=(tsquery,tsquery)', oprcode => 'tsquery_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3675', descr => 'less than or equal',
oprname => '<=', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '>=(tsquery,tsquery)',
oprnegate => '>(tsquery,tsquery)', oprcode => 'tsquery_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3676', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprleft => 'tsquery',
oprright => 'tsquery', oprresult => 'bool', oprcom => '=(tsquery,tsquery)',
oprnegate => '<>(tsquery,tsquery)', oprcode => 'tsquery_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '3677', descr => 'not equal',
oprname => '<>', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '<>(tsquery,tsquery)',
oprnegate => '=(tsquery,tsquery)', oprcode => 'tsquery_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3678', descr => 'greater than or equal',
oprname => '>=', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '<=(tsquery,tsquery)',
oprnegate => '<(tsquery,tsquery)', oprcode => 'tsquery_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
{ oid => '3679', descr => 'greater than',
oprname => '>', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '<(tsquery,tsquery)',
oprnegate => '<=(tsquery,tsquery)', oprcode => 'tsquery_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3680', descr => 'AND-concatenate',
oprname => '&&', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'tsquery', oprcode => 'tsquery_and' },
{ oid => '3681', descr => 'OR-concatenate',
oprname => '||', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'tsquery', oprcode => 'tsquery_or' },
{ oid => '5005', descr => 'phrase-concatenate',
oprname => '<->', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'tsquery', oprcode => 'tsquery_phrase(tsquery,tsquery)' },
{ oid => '3682', descr => 'NOT tsquery',
oprname => '!!', oprkind => 'l', oprleft => '0', oprright => 'tsquery',
oprresult => 'tsquery', oprcode => 'tsquery_not' },
{ oid => '3693', descr => 'contains',
oprname => '@>', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '<@(tsquery,tsquery)',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'tsq_mcontains', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3694', descr => 'is contained by',
oprname => '<@', oprleft => 'tsquery', oprright => 'tsquery',
oprresult => 'bool', oprcom => '@>(tsquery,tsquery)',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'tsq_mcontained', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3762', descr => 'text search match',
oprname => '@@', oprleft => 'text', oprright => 'text', oprresult => 'bool',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'ts_match_tt', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3763', descr => 'text search match',
oprname => '@@', oprleft => 'text', oprright => 'tsquery',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprresult => 'bool', oprcode => 'ts_match_tq', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
# generic record comparison operators
{ oid => '2988', oid_symbol => 'RECORD_EQ_OP', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'record',
oprright => 'record', oprresult => 'bool', oprcom => '=(record,record)',
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
oprnegate => '<>(record,record)', oprcode => 'record_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '2989', descr => 'not equal',
oprname => '<>', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '<>(record,record)',
oprnegate => '=(record,record)', oprcode => 'record_ne', oprrest => 'neqsel',
oprjoin => 'neqjoinsel' },
{ oid => '2990', oid_symbol => 'RECORD_LT_OP', descr => 'less than',
oprname => '<', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '>(record,record)',
oprnegate => '>=(record,record)', oprcode => 'record_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '2991', oid_symbol => 'RECORD_GT_OP', descr => 'greater than',
oprname => '>', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '<(record,record)',
oprnegate => '<=(record,record)', oprcode => 'record_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '2992', descr => 'less than or equal',
oprname => '<=', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '>=(record,record)',
oprnegate => '>(record,record)', oprcode => 'record_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2993', descr => 'greater than or equal',
oprname => '>=', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '<=(record,record)',
oprnegate => '<(record,record)', oprcode => 'record_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# byte-oriented tests for identical rows and fast sorting
{ oid => '3188', descr => 'identical',
oprname => '*=', oprcanmerge => 't', oprleft => 'record',
oprright => 'record', oprresult => 'bool', oprcom => '*=(record,record)',
oprnegate => '*<>(record,record)', oprcode => 'record_image_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '3189', descr => 'not identical',
oprname => '*<>', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '*<>(record,record)',
oprnegate => '*=(record,record)', oprcode => 'record_image_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3190', descr => 'less than',
oprname => '*<', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '*>(record,record)',
oprnegate => '*>=(record,record)', oprcode => 'record_image_lt',
oprrest => 'scalarltsel', oprjoin => 'scalarltjoinsel' },
{ oid => '3191', descr => 'greater than',
oprname => '*>', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '*<(record,record)',
oprnegate => '*<=(record,record)', oprcode => 'record_image_gt',
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
{ oid => '3192', descr => 'less than or equal',
oprname => '*<=', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '*>=(record,record)',
oprnegate => '*>(record,record)', oprcode => 'record_image_le',
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3193', descr => 'greater than or equal',
oprname => '*>=', oprleft => 'record', oprright => 'record',
oprresult => 'bool', oprcom => '*<=(record,record)',
oprnegate => '*<(record,record)', oprcode => 'record_image_ge',
oprrest => 'scalargesel', oprjoin => 'scalargejoinsel' },
# generic range type operators
{ oid => '3882', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'anyrange',
oprright => 'anyrange', oprresult => 'bool', oprcom => '=(anyrange,anyrange)',
oprnegate => '<>(anyrange,anyrange)', oprcode => 'range_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '3883', descr => 'not equal',
oprname => '<>', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<>(anyrange,anyrange)',
oprnegate => '=(anyrange,anyrange)', oprcode => 'range_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3884', oid_symbol => 'OID_RANGE_LESS_OP', descr => 'less than',
oprname => '<', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '>(anyrange,anyrange)',
oprnegate => '>=(anyrange,anyrange)', oprcode => 'range_lt',
oprrest => 'rangesel', oprjoin => 'scalarltjoinsel' },
{ oid => '3885', oid_symbol => 'OID_RANGE_LESS_EQUAL_OP',
descr => 'less than or equal',
oprname => '<=', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '>=(anyrange,anyrange)',
oprnegate => '>(anyrange,anyrange)', oprcode => 'range_le',
oprrest => 'rangesel', oprjoin => 'scalarlejoinsel' },
{ oid => '3886', oid_symbol => 'OID_RANGE_GREATER_EQUAL_OP',
descr => 'greater than or equal',
oprname => '>=', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<=(anyrange,anyrange)',
oprnegate => '<(anyrange,anyrange)', oprcode => 'range_ge',
oprrest => 'rangesel', oprjoin => 'scalargejoinsel' },
{ oid => '3887', oid_symbol => 'OID_RANGE_GREATER_OP',
descr => 'greater than',
oprname => '>', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<(anyrange,anyrange)',
oprnegate => '<=(anyrange,anyrange)', oprcode => 'range_gt',
oprrest => 'rangesel', oprjoin => 'scalargtjoinsel' },
{ oid => '3888', oid_symbol => 'OID_RANGE_OVERLAP_OP', descr => 'overlaps',
oprname => '&&', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '&&(anyrange,anyrange)',
oprcode => 'range_overlaps', oprrest => 'rangesel',
oprjoin => 'areajoinsel' },
{ oid => '3889', oid_symbol => 'OID_RANGE_CONTAINS_ELEM_OP',
descr => 'contains',
oprname => '@>', oprleft => 'anyrange', oprright => 'anyelement',
oprresult => 'bool', oprcom => '<@(anyelement,anyrange)',
oprcode => 'range_contains_elem', oprrest => 'rangesel',
oprjoin => 'contjoinsel' },
{ oid => '3890', oid_symbol => 'OID_RANGE_CONTAINS_OP', descr => 'contains',
oprname => '@>', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<@(anyrange,anyrange)',
oprcode => 'range_contains', oprrest => 'rangesel',
oprjoin => 'contjoinsel' },
{ oid => '3891', oid_symbol => 'OID_RANGE_ELEM_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anyelement', oprright => 'anyrange',
oprresult => 'bool', oprcom => '@>(anyrange,anyelement)',
oprcode => 'elem_contained_by_range', oprrest => 'rangesel',
oprjoin => 'contjoinsel' },
{ oid => '3892', oid_symbol => 'OID_RANGE_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '@>(anyrange,anyrange)',
oprcode => 'range_contained_by', oprrest => 'rangesel',
oprjoin => 'contjoinsel' },
{ oid => '3893', oid_symbol => 'OID_RANGE_LEFT_OP', descr => 'is left of',
oprname => '<<', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '>>(anyrange,anyrange)',
oprcode => 'range_before', oprrest => 'rangesel',
oprjoin => 'scalarltjoinsel' },
{ oid => '3894', oid_symbol => 'OID_RANGE_RIGHT_OP', descr => 'is right of',
oprname => '>>', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<<(anyrange,anyrange)',
oprcode => 'range_after', oprrest => 'rangesel',
oprjoin => 'scalargtjoinsel' },
{ oid => '3895', oid_symbol => 'OID_RANGE_OVERLAPS_LEFT_OP',
descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcode => 'range_overleft', oprrest => 'rangesel',
oprjoin => 'scalarltjoinsel' },
{ oid => '3896', oid_symbol => 'OID_RANGE_OVERLAPS_RIGHT_OP',
descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcode => 'range_overright', oprrest => 'rangesel',
oprjoin => 'scalargtjoinsel' },
{ oid => '3897', descr => 'is adjacent to',
oprname => '-|-', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '-|-(anyrange,anyrange)',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'range_adjacent', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3898', descr => 'range union',
oprname => '+', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'anyrange', oprcom => '+(anyrange,anyrange)',
oprcode => 'range_union' },
{ oid => '3899', descr => 'range difference',
oprname => '-', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'anyrange', oprcode => 'range_minus' },
{ oid => '3900', descr => 'range intersection',
oprname => '*', oprleft => 'anyrange', oprright => 'anyrange',
oprresult => 'anyrange', oprcom => '*(anyrange,anyrange)',
oprcode => 'range_intersect' },
{ oid => '3962', descr => 'get json object field',
oprname => '->', oprleft => 'json', oprright => 'text', oprresult => 'json',
oprcode => 'json_object_field' },
{ oid => '3963', descr => 'get json object field as text',
oprname => '->>', oprleft => 'json', oprright => 'text', oprresult => 'text',
oprcode => 'json_object_field_text' },
{ oid => '3964', descr => 'get json array element',
oprname => '->', oprleft => 'json', oprright => 'int4', oprresult => 'json',
oprcode => 'json_array_element' },
{ oid => '3965', descr => 'get json array element as text',
oprname => '->>', oprleft => 'json', oprright => 'int4', oprresult => 'text',
oprcode => 'json_array_element_text' },
{ oid => '3966', descr => 'get value from json with path elements',
oprname => '#>', oprleft => 'json', oprright => '_text', oprresult => 'json',
oprcode => 'json_extract_path' },
{ oid => '3967', descr => 'get value from json as text with path elements',
oprname => '#>>', oprleft => 'json', oprright => '_text', oprresult => 'text',
oprcode => 'json_extract_path_text' },
{ oid => '3211', descr => 'get jsonb object field',
oprname => '->', oprleft => 'jsonb', oprright => 'text', oprresult => 'jsonb',
oprcode => 'jsonb_object_field' },
{ oid => '3477', descr => 'get jsonb object field as text',
oprname => '->>', oprleft => 'jsonb', oprright => 'text', oprresult => 'text',
oprcode => 'jsonb_object_field_text' },
{ oid => '3212', descr => 'get jsonb array element',
oprname => '->', oprleft => 'jsonb', oprright => 'int4', oprresult => 'jsonb',
oprcode => 'jsonb_array_element' },
{ oid => '3481', descr => 'get jsonb array element as text',
oprname => '->>', oprleft => 'jsonb', oprright => 'int4', oprresult => 'text',
oprcode => 'jsonb_array_element_text' },
{ oid => '3213', descr => 'get value from jsonb with path elements',
oprname => '#>', oprleft => 'jsonb', oprright => '_text',
oprresult => 'jsonb', oprcode => 'jsonb_extract_path' },
{ oid => '3206', descr => 'get value from jsonb as text with path elements',
oprname => '#>>', oprleft => 'jsonb', oprright => '_text',
oprresult => 'text', oprcode => 'jsonb_extract_path_text' },
{ oid => '3240', descr => 'equal',
oprname => '=', oprcanmerge => 't', oprcanhash => 't', oprleft => 'jsonb',
oprright => 'jsonb', oprresult => 'bool', oprcom => '=(jsonb,jsonb)',
oprnegate => '<>(jsonb,jsonb)', oprcode => 'jsonb_eq', oprrest => 'eqsel',
oprjoin => 'eqjoinsel' },
{ oid => '3241', descr => 'not equal',
oprname => '<>', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '<>(jsonb,jsonb)', oprnegate => '=(jsonb,jsonb)',
oprcode => 'jsonb_ne', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '3242', descr => 'less than',
oprname => '<', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '>(jsonb,jsonb)', oprnegate => '>=(jsonb,jsonb)',
oprcode => 'jsonb_lt', oprrest => 'scalarltsel',
oprjoin => 'scalarltjoinsel' },
{ oid => '3243', descr => 'greater than',
oprname => '>', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '<(jsonb,jsonb)', oprnegate => '<=(jsonb,jsonb)',
oprcode => 'jsonb_gt', oprrest => 'scalargtsel',
oprjoin => 'scalargtjoinsel' },
{ oid => '3244', descr => 'less than or equal',
oprname => '<=', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '>=(jsonb,jsonb)', oprnegate => '>(jsonb,jsonb)',
oprcode => 'jsonb_le', oprrest => 'scalarlesel',
oprjoin => 'scalarlejoinsel' },
{ oid => '3245', descr => 'greater than or equal',
oprname => '>=', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '<=(jsonb,jsonb)', oprnegate => '<(jsonb,jsonb)',
oprcode => 'jsonb_ge', oprrest => 'scalargesel',
oprjoin => 'scalargejoinsel' },
{ oid => '3246', descr => 'contains',
oprname => '@>', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '<@(jsonb,jsonb)', oprcode => 'jsonb_contains',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprrest => 'matchingsel', oprjoin => 'matchingjoinsel' },
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
{ oid => '3247', descr => 'key exists',
oprname => '?', oprleft => 'jsonb', oprright => 'text', oprresult => 'bool',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'jsonb_exists', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3248', descr => 'any key exists',
oprname => '?|', oprleft => 'jsonb', oprright => '_text', oprresult => 'bool',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'jsonb_exists_any', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3249', descr => 'all keys exist',
oprname => '?&', oprleft => 'jsonb', oprright => '_text', oprresult => 'bool',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprcode => 'jsonb_exists_all', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '3250', descr => 'is contained by',
oprname => '<@', oprleft => 'jsonb', oprright => 'jsonb', oprresult => 'bool',
oprcom => '@>(jsonb,jsonb)', oprcode => 'jsonb_contained',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprrest => 'matchingsel', oprjoin => 'matchingjoinsel' },
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
{ oid => '3284', descr => 'concatenate',
oprname => '||', oprleft => 'jsonb', oprright => 'jsonb',
oprresult => 'jsonb', oprcode => 'jsonb_concat' },
{ oid => '3285', descr => 'delete object field',
oprname => '-', oprleft => 'jsonb', oprright => 'text', oprresult => 'jsonb',
oprcode => 'jsonb_delete(jsonb,text)' },
{ oid => '3398', descr => 'delete object fields',
oprname => '-', oprleft => 'jsonb', oprright => '_text', oprresult => 'jsonb',
oprcode => 'jsonb_delete(jsonb,_text)' },
{ oid => '3286', descr => 'delete array element',
oprname => '-', oprleft => 'jsonb', oprright => 'int4', oprresult => 'jsonb',
oprcode => 'jsonb_delete(jsonb,int4)' },
{ oid => '3287', descr => 'delete path',
oprname => '#-', oprleft => 'jsonb', oprright => '_text',
oprresult => 'jsonb', oprcode => 'jsonb_delete_path' },
Partial implementation of SQL/JSON path language SQL 2016 standards among other things contains set of SQL/JSON features for JSON processing inside of relational database. The core of SQL/JSON is JSON path language, allowing access parts of JSON documents and make computations over them. This commit implements partial support JSON path language as separate datatype called "jsonpath". The implementation is partial because it's lacking datetime support and suppression of numeric errors. Missing features will be added later by separate commits. Support of SQL/JSON features requires implementation of separate nodes, and it will be considered in subsequent patches. This commit includes following set of plain functions, allowing to execute jsonpath over jsonb values: * jsonb_path_exists(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_match(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_query(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_query_array(jsonb, jsonpath[, jsonb, bool]). * jsonb_path_query_first(jsonb, jsonpath[, jsonb, bool]). This commit also implements "jsonb @? jsonpath" and "jsonb @@ jsonpath", which are wrappers over jsonpath_exists(jsonb, jsonpath) and jsonpath_predicate(jsonb, jsonpath) correspondingly. These operators will have an index support (implemented in subsequent patches). Catversion bumped, to add new functions and operators. Code was written by Nikita Glukhov and Teodor Sigaev, revised by me. Documentation was written by Oleg Bartunov and Liudmila Mantrova. The work was inspired by Oleg Bartunov. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova Reviewed-by: Tomas Vondra, Andrew Dunstan, Pavel Stehule, Alexander Korotkov
2019-03-16 10:15:37 +01:00
{ oid => '4012', descr => 'jsonpath exists',
oprname => '@?', oprleft => 'jsonb', oprright => 'jsonpath',
Remove ambiguity for jsonb_path_match() and jsonb_path_exists() There are 2-arguments and 4-arguments versions of jsonb_path_match() and jsonb_path_exists(). But 4-arguments versions have optional 3rd and 4th arguments, that leads to ambiguity. In the same time 2-arguments versions are needed only for @@ and @? operators. So, rename 2-arguments versions to remove the ambiguity. Catversion is bumped.
2019-03-20 08:27:56 +01:00
oprresult => 'bool', oprcode => 'jsonb_path_exists_opr(jsonb,jsonpath)',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprrest => 'matchingsel', oprjoin => 'matchingjoinsel' },
Partial implementation of SQL/JSON path language SQL 2016 standards among other things contains set of SQL/JSON features for JSON processing inside of relational database. The core of SQL/JSON is JSON path language, allowing access parts of JSON documents and make computations over them. This commit implements partial support JSON path language as separate datatype called "jsonpath". The implementation is partial because it's lacking datetime support and suppression of numeric errors. Missing features will be added later by separate commits. Support of SQL/JSON features requires implementation of separate nodes, and it will be considered in subsequent patches. This commit includes following set of plain functions, allowing to execute jsonpath over jsonb values: * jsonb_path_exists(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_match(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_query(jsonb, jsonpath[, jsonb, bool]), * jsonb_path_query_array(jsonb, jsonpath[, jsonb, bool]). * jsonb_path_query_first(jsonb, jsonpath[, jsonb, bool]). This commit also implements "jsonb @? jsonpath" and "jsonb @@ jsonpath", which are wrappers over jsonpath_exists(jsonb, jsonpath) and jsonpath_predicate(jsonb, jsonpath) correspondingly. These operators will have an index support (implemented in subsequent patches). Catversion bumped, to add new functions and operators. Code was written by Nikita Glukhov and Teodor Sigaev, revised by me. Documentation was written by Oleg Bartunov and Liudmila Mantrova. The work was inspired by Oleg Bartunov. Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com Author: Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova Reviewed-by: Tomas Vondra, Andrew Dunstan, Pavel Stehule, Alexander Korotkov
2019-03-16 10:15:37 +01:00
{ oid => '4013', descr => 'jsonpath match',
oprname => '@@', oprleft => 'jsonb', oprright => 'jsonpath',
Remove ambiguity for jsonb_path_match() and jsonb_path_exists() There are 2-arguments and 4-arguments versions of jsonb_path_match() and jsonb_path_exists(). But 4-arguments versions have optional 3rd and 4th arguments, that leads to ambiguity. In the same time 2-arguments versions are needed only for @@ and @? operators. So, rename 2-arguments versions to remove the ambiguity. Catversion is bumped.
2019-03-20 08:27:56 +01:00
oprresult => 'bool', oprcode => 'jsonb_path_match_opr(jsonb,jsonpath)',
Improve selectivity estimation for assorted match-style operators. Quite a few matching operators such as JSONB's @> used "contsel" and "contjoinsel" as their selectivity estimators. That was a bad idea, because (a) contsel is only a stub, yielding a fixed default estimate, and (b) that default is 0.001, meaning we estimate these operators as five times more selective than equality, which is surely pretty silly. There's a good model for improving this in ltree's ltreeparentsel(): for any "var OP constant" query, we can try applying the operator to all of the column's MCV and histogram values, taking the latter as being a random sample of the non-MCV values. That code is actually 100% generic, except for the question of exactly what default selectivity ought to be plugged in when we don't have stats. Hence, migrate the guts of ltreeparentsel() into the core code, provide wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate default estimate, and use those for the non-geometric operators that formerly used contsel (mostly JSONB containment operators and tsquery matching). Also apply this code to some match-like operators in hstore, ltree, and pg_trgm, including the former users of ltreeparentsel as well as ones that improperly used contsel. Since commit 911e70207 just created new versions of those extensions that we haven't released yet, we can sneak this change into those new versions instead of having to create an additional generation of update scripts. Patch by me, reviewed by Alexey Bashtanov Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us
2020-04-01 16:32:33 +02:00
oprrest => 'matchingsel', oprjoin => 'matchingjoinsel' },
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
{ oid => '2860', descr => 'equal',
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
oprname => '=', oprcanmerge => 't', oprcanhash => 't',
oprleft => 'anymultirange', oprright => 'anymultirange', oprresult => 'bool',
oprcom => '=(anymultirange,anymultirange)',
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
oprnegate => '<>(anymultirange,anymultirange)', oprcode => 'multirange_eq',
oprrest => 'eqsel', oprjoin => 'eqjoinsel' },
{ oid => '2861', descr => 'not equal',
oprname => '<>', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<>(anymultirange,anymultirange)',
oprnegate => '=(anymultirange,anymultirange)', oprcode => 'multirange_ne',
oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
{ oid => '2862', oid_symbol => 'OID_MULTIRANGE_LESS_OP', descr => 'less than',
oprname => '<', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '>(anymultirange,anymultirange)',
oprnegate => '>=(anymultirange,anymultirange)', oprcode => 'multirange_lt',
oprrest => 'multirangesel', oprjoin => 'scalarltjoinsel' },
{ oid => '2863', oid_symbol => 'OID_MULTIRANGE_LESS_EQUAL_OP',
descr => 'less than or equal',
oprname => '<=', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '>=(anymultirange,anymultirange)',
oprnegate => '>(anymultirange,anymultirange)', oprcode => 'multirange_le',
oprrest => 'multirangesel', oprjoin => 'scalarlejoinsel' },
{ oid => '2864', oid_symbol => 'OID_MULTIRANGE_GREATER_EQUAL_OP',
descr => 'greater than or equal',
oprname => '>=', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<=(anymultirange,anymultirange)',
oprnegate => '<(anymultirange,anymultirange)', oprcode => 'multirange_ge',
oprrest => 'multirangesel', oprjoin => 'scalargejoinsel' },
{ oid => '2865', oid_symbol => 'OID_MULTIRANGE_GREATER_OP',
descr => 'greater than',
oprname => '>', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<(anymultirange,anymultirange)',
oprnegate => '<=(anymultirange,anymultirange)', oprcode => 'multirange_gt',
oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
{ oid => '2866', oid_symbol => 'OID_RANGE_OVERLAPS_MULTIRANGE_OP',
descr => 'overlaps',
oprname => '&&', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '&&(anymultirange,anyrange)',
oprcode => 'range_overlaps_multirange', oprrest => 'multirangesel',
oprjoin => 'areajoinsel' },
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
{ oid => '2867', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_RANGE_OP',
descr => 'contains',
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
oprname => '&&', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '&&(anyrange,anymultirange)',
oprcode => 'multirange_overlaps_range', oprrest => 'multirangesel',
oprjoin => 'areajoinsel' },
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
{ oid => '2868', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_MULTIRANGE_OP',
descr => 'contains',
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
oprname => '&&', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '&&(anymultirange,anymultirange)',
oprcode => 'multirange_overlaps_multirange', oprrest => 'multirangesel',
oprjoin => 'areajoinsel' },
{ oid => '2869', oid_symbol => 'OID_MULTIRANGE_CONTAINS_ELEM_OP',
descr => 'contains',
oprname => '@>', oprleft => 'anymultirange', oprright => 'anyelement',
oprresult => 'bool', oprcom => '<@(anyelement,anymultirange)',
oprcode => 'multirange_contains_elem', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
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
{ oid => '2870', oid_symbol => 'OID_MULTIRANGE_CONTAINS_RANGE_OP',
descr => 'contains',
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
oprname => '@>', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<@(anyrange,anymultirange)',
oprcode => 'multirange_contains_range', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
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
{ oid => '2871', oid_symbol => 'OID_MULTIRANGE_CONTAINS_MULTIRANGE_OP',
descr => 'contains',
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
oprname => '@>', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<@(anymultirange,anymultirange)',
oprcode => 'multirange_contains_multirange', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
{ oid => '2872', oid_symbol => 'OID_MULTIRANGE_ELEM_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anyelement', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '@>(anymultirange,anyelement)',
oprcode => 'elem_contained_by_multirange', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
{ oid => '2873', oid_symbol => 'OID_MULTIRANGE_RANGE_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '@>(anymultirange,anyrange)',
oprcode => 'range_contained_by_multirange', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
{ oid => '2874', oid_symbol => 'OID_MULTIRANGE_MULTIRANGE_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '@>(anymultirange,anymultirange)',
oprcode => 'multirange_contained_by_multirange', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
Implement operators for checking if the range contains a multirange We have operators for checking if the multirange contains a range but don't have the opposite. This commit improves completeness of the operator set by adding two new operators: @> (anyrange,anymultirange) and <@(anymultirange,anyrange). Catversion is bumped.
2020-12-29 21:35:33 +01:00
{ oid => '4539', oid_symbol => 'OID_RANGE_CONTAINS_MULTIRANGE_OP',
descr => 'contains',
oprname => '@>', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<@(anymultirange,anyrange)',
oprcode => 'range_contains_multirange', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
{ oid => '4540', oid_symbol => 'OID_RANGE_MULTIRANGE_CONTAINED_OP',
descr => 'is contained by',
oprname => '<@', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '@>(anyrange,anymultirange)',
oprcode => 'multirange_contained_by_range', oprrest => 'multirangesel',
oprjoin => 'contjoinsel' },
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
{ oid => '2875', oid_symbol => 'OID_RANGE_OVERLAPS_LEFT_MULTIRANGE_OP',
descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'anyrange', oprright => 'anymultirange',
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
oprresult => 'bool', oprcode => 'range_overleft_multirange',
oprrest => 'multirangesel', oprjoin => 'scalarltjoinsel' },
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
{ oid => '2876', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_LEFT_RANGE_OP',
descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'anymultirange', oprright => 'anyrange',
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
oprresult => 'bool', oprcode => 'multirange_overleft_range',
oprrest => 'multirangesel', oprjoin => 'scalarltjoinsel' },
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
{ oid => '2877', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_LEFT_MULTIRANGE_OP',
descr => 'overlaps or is left of',
oprname => '&<', oprleft => 'anymultirange', oprright => 'anymultirange',
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
oprresult => 'bool', oprcode => 'multirange_overleft_multirange',
oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
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
{ oid => '3585', oid_symbol => 'OID_RANGE_OVERLAPS_RIGHT_MULTIRANGE_OP',
descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'anyrange', oprright => 'anymultirange',
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
oprresult => 'bool', oprcode => 'range_overright_multirange',
oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
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
{ oid => '4035', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_RIGHT_RANGE_OP',
descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'anymultirange', oprright => 'anyrange',
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
oprresult => 'bool', oprcode => 'multirange_overright_range',
oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
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
{ oid => '4142', oid_symbol => 'OID_MULTIRANGE_OVERLAPS_RIGHT_MULTIRANGE_OP',
descr => 'overlaps or is right of',
oprname => '&>', oprleft => 'anymultirange', oprright => 'anymultirange',
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
oprresult => 'bool', oprcode => 'multirange_overright_multirange',
oprrest => 'multirangesel', oprjoin => 'scalargtjoinsel' },
{ oid => '4179', oid_symbol => 'OID_RANGE_ADJACENT_MULTIRANGE_OP',
descr => 'is adjacent to',
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
oprname => '-|-', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '-|-(anymultirange,anyrange)',
oprcode => 'range_adjacent_multirange', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '4180', oid_symbol => 'OID_MULTIRANGE_ADJACENT_RANGE_OP',
descr => 'is adjacent to',
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
oprname => '-|-', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '-|-(anyrange,anymultirange)',
oprcode => 'multirange_adjacent_range', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
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
{ oid => '4198', oid_symbol => 'OID_MULTIRANGE_ADJACENT_MULTIRANGE_OP',
descr => 'is adjacent to',
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
oprname => '-|-', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '-|-(anymultirange,anymultirange)',
oprcode => 'multirange_adjacent_multirange', oprrest => 'matchingsel',
oprjoin => 'matchingjoinsel' },
{ oid => '4392', descr => 'multirange union',
oprname => '+', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'anymultirange', oprcom => '+(anymultirange,anymultirange)',
oprcode => 'multirange_union' },
{ oid => '4393', descr => 'multirange minus',
oprname => '-', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'anymultirange', oprcode => 'multirange_minus' },
{ oid => '4394', descr => 'multirange intersect',
oprname => '*', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'anymultirange', oprcom => '*(anymultirange,anymultirange)',
oprcode => 'multirange_intersect' },
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
{ oid => '4395', oid_symbol => 'OID_RANGE_LEFT_MULTIRANGE_OP',
descr => 'is left of',
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
oprname => '<<', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '>>(anymultirange,anyrange)',
oprcode => 'range_before_multirange', oprrest => 'multirangesel',
oprjoin => 'scalarltjoinsel' },
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
{ oid => '4396', oid_symbol => 'OID_MULTIRANGE_LEFT_RANGE_OP',
descr => 'is left of',
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
oprname => '<<', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '>>(anyrange,anymultirange)',
oprcode => 'multirange_before_range', oprrest => 'multirangesel',
oprjoin => 'scalarltjoinsel' },
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
{ oid => '4397', oid_symbol => 'OID_MULTIRANGE_LEFT_MULTIRANGE_OP',
descr => 'is left of',
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
oprname => '<<', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '>>(anymultirange,anymultirange)',
oprcode => 'multirange_before_multirange', oprrest => 'multirangesel',
oprjoin => 'scalarltjoinsel' },
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
{ oid => '4398', oid_symbol => 'OID_RANGE_RIGHT_MULTIRANGE_OP',
descr => 'is right of',
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
oprname => '>>', oprleft => 'anyrange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<<(anymultirange,anyrange)',
oprcode => 'range_after_multirange', oprrest => 'multirangesel',
oprjoin => 'scalargtjoinsel' },
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
{ oid => '4399', oid_symbol => 'OID_MULTIRANGE_RIGHT_RANGE_OP',
descr => 'is right of',
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
oprname => '>>', oprleft => 'anymultirange', oprright => 'anyrange',
oprresult => 'bool', oprcom => '<<(anyrange,anymultirange)',
oprcode => 'multirange_after_range', oprrest => 'multirangesel',
oprjoin => 'scalargtjoinsel' },
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
{ oid => '4400', oid_symbol => 'OID_MULTIRANGE_RIGHT_MULTIRANGE_OP',
descr => 'is right of',
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
oprname => '>>', oprleft => 'anymultirange', oprright => 'anymultirange',
oprresult => 'bool', oprcom => '<<(anymultirange,anymultirange)',
oprcode => 'multirange_after_multirange', oprrest => 'multirangesel',
oprjoin => 'scalargtjoinsel' },
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
]