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
|
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
|
|
|
#
|
2020-01-01 18:21:45 +01:00
|
|
|
# Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
Replace our traditional initial-catalog-data format with a better design.
Historically, the initial catalog data to be installed during bootstrap
has been written in DATA() lines in the catalog header files. This had
lots of disadvantages: the format was badly underdocumented, it was
very difficult to edit the data in any mechanized way, and due to the
lack of any abstraction the data was verbose, hard to read/understand,
and easy to get wrong.
Hence, move this data into separate ".dat" files and represent it in a way
that can easily be read and rewritten by Perl scripts. The new format is
essentially "key => value" for each column; while it's a bit repetitive,
explicit labeling of each value makes the data far more readable and less
error-prone. Provide a way to abbreviate entries by omitting field values
that match a specified default value for their column. This allows removal
of a large amount of repetitive boilerplate and also lowers the barrier to
adding new columns.
Also teach genbki.pl how to translate symbolic OID references into
numeric OIDs for more cases than just "regproc"-like pg_proc references.
It can now do that for regprocedure-like references (thus solving the
problem that regproc is ambiguous for overloaded functions), operators,
types, opfamilies, opclasses, and access methods. Use this to turn
nearly all OID cross-references in the initial data into symbolic form.
This represents a very large step forward in readability and error
resistance of the initial catalog data. It should also reduce the
difficulty of renumbering OID assignments in uncommitted patches.
Also, solve the longstanding problem that frontend code that would like to
use OID macros and other information from the catalog headers often had
difficulty with backend-only code in the headers. To do this, arrange for
all generated macros, plus such other declarations as we deem fit, to be
placed in "derived" header files that are safe for frontend inclusion.
(Once clients migrate to using these pg_*_d.h headers, it will be possible
to get rid of the pg_*_fn.h headers, which only exist to quarantine code
away from clients. That is left for follow-on patches, however.)
The now-automatically-generated macros include the Anum_xxx and Natts_xxx
constants that we used to have to update by hand when adding or removing
catalog columns.
Replace the former manual method of generating OID macros for pg_type
entries with an automatic method, ensuring that all built-in types have
OID macros. (But note that this patch does not change the way that
OID macros for pg_proc entries are built and used. It's not clear that
making that match the other catalogs would be worth extra code churn.)
Add SGML documentation explaining what the new data format is and how to
work with it.
Despite being a very large change in the catalog headers, there is no
catversion bump here, because postgres.bki and related output files
haven't changed at all.
John Naylor, based on ideas from various people; review and minor
additional coding by me; previous review by Alvaro Herrera
Discussion: https://postgr.es/m/CAJVSVGWO48JbbwXkJz_yBFyGYW-M9YWxnPdxJBUosDC9ou_F0Q@mail.gmail.com
2018-04-08 19:16:50 +02:00
|
|
|
# Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
#
|
|
|
|
# src/include/catalog/pg_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',
|
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',
|
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',
|
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',
|
|
|
|
oprname => '||', oprleft => 'anyarray', oprright => 'anyelement',
|
|
|
|
oprresult => 'anyarray', oprcode => 'array_append' },
|
|
|
|
{ oid => '374', descr => 'prepend element onto front of array',
|
|
|
|
oprname => '||', oprleft => 'anyelement', oprright => 'anyarray',
|
|
|
|
oprresult => 'anyarray', oprcode => 'array_prepend' },
|
|
|
|
{ oid => '375', descr => 'concatenate',
|
|
|
|
oprname => '||', oprleft => 'anyarray', oprright => 'anyarray',
|
|
|
|
oprresult => 'anyarray', oprcode => 'array_cat' },
|
|
|
|
|
|
|
|
{ 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' },
|
|
|
|
{ oid => '388', descr => 'factorial',
|
|
|
|
oprname => '!', oprkind => 'r', oprleft => 'int8', oprright => '0',
|
|
|
|
oprresult => 'numeric', oprcode => 'numeric_fac' },
|
|
|
|
{ oid => '389', descr => 'deprecated, use ! instead',
|
|
|
|
oprname => '!!', oprkind => 'l', oprleft => '0', oprright => 'int8',
|
|
|
|
oprresult => 'numeric', oprcode => 'numeric_fac' },
|
|
|
|
{ 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',
|
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' },
|
|
|
|
{ oid => '2800', descr => 'greater than',
|
|
|
|
oprname => '>', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
|
|
|
|
oprcom => '<(tid,tid)', oprnegate => '<=(tid,tid)', oprcode => 'tidgt',
|
|
|
|
oprrest => 'scalargtsel', oprjoin => 'scalargtjoinsel' },
|
|
|
|
{ oid => '2801', descr => 'less than or equal',
|
|
|
|
oprname => '<=', oprleft => 'tid', oprright => 'tid', oprresult => 'bool',
|
|
|
|
oprcom => '>=(tid,tid)', oprnegate => '>(tid,tid)', oprcode => 'tidle',
|
|
|
|
oprrest => 'scalarlesel', oprjoin => 'scalarlejoinsel' },
|
|
|
|
{ oid => '2802', descr => 'greater than or equal',
|
|
|
|
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' },
|
|
|
|
{ oid => '506', descr => 'is above',
|
|
|
|
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' },
|
|
|
|
{ oid => '509', descr => 'is below',
|
|
|
|
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' },
|
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' },
|
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',
|
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',
|
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',
|
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',
|
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',
|
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',
|
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' },
|
|
|
|
|
|
|
|
# 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' },
|
|
|
|
|
|
|
|
# obsolete names for contains/contained-by operators; remove these someday
|
|
|
|
{ oid => '2860', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'polygon', oprright => 'polygon',
|
|
|
|
oprresult => 'bool', oprcom => '~(polygon,polygon)',
|
|
|
|
oprcode => 'poly_contained', oprrest => 'contsel', oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2861', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'polygon', oprright => 'polygon',
|
|
|
|
oprresult => 'bool', oprcom => '@(polygon,polygon)',
|
|
|
|
oprcode => 'poly_contain', oprrest => 'contsel', oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2862', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'box', oprright => 'box', oprresult => 'bool',
|
|
|
|
oprcom => '~(box,box)', oprcode => 'box_contained', oprrest => 'contsel',
|
|
|
|
oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2863', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'box', oprright => 'box', oprresult => 'bool',
|
|
|
|
oprcom => '@(box,box)', oprcode => 'box_contain', oprrest => 'contsel',
|
|
|
|
oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2864', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'circle', oprright => 'circle',
|
|
|
|
oprresult => 'bool', oprcom => '~(circle,circle)',
|
|
|
|
oprcode => 'circle_contained', oprrest => 'contsel',
|
|
|
|
oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2865', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'circle', oprright => 'circle',
|
|
|
|
oprresult => 'bool', oprcom => '@(circle,circle)',
|
|
|
|
oprcode => 'circle_contain', oprrest => 'contsel', oprjoin => 'contjoinsel' },
|
|
|
|
{ oid => '2866', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'box', oprresult => 'bool',
|
|
|
|
oprcode => 'on_pb' },
|
|
|
|
{ oid => '2867', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'path', oprresult => 'bool',
|
|
|
|
oprcom => '~(path,point)', oprcode => 'on_ppath' },
|
|
|
|
{ oid => '2868', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'path', oprright => 'point', oprresult => 'bool',
|
|
|
|
oprcom => '@(point,path)', oprcode => 'path_contain_pt' },
|
|
|
|
{ oid => '2869', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'polygon',
|
|
|
|
oprresult => 'bool', oprcom => '~(polygon,point)',
|
|
|
|
oprcode => 'pt_contained_poly' },
|
|
|
|
{ oid => '2870', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'polygon', oprright => 'point',
|
|
|
|
oprresult => 'bool', oprcom => '@(point,polygon)',
|
|
|
|
oprcode => 'poly_contain_pt' },
|
|
|
|
{ oid => '2871', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'circle', oprresult => 'bool',
|
|
|
|
oprcom => '~(circle,point)', oprcode => 'pt_contained_circle' },
|
|
|
|
{ oid => '2872', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => 'circle', oprright => 'point', oprresult => 'bool',
|
|
|
|
oprcom => '@(point,circle)', oprcode => 'circle_contain_pt' },
|
|
|
|
{ oid => '2873', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'line', oprresult => 'bool',
|
|
|
|
oprcode => 'on_pl' },
|
|
|
|
{ oid => '2874', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'point', oprright => 'lseg', oprresult => 'bool',
|
|
|
|
oprcode => 'on_ps' },
|
|
|
|
{ oid => '2875', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'lseg', oprright => 'line', oprresult => 'bool',
|
|
|
|
oprcode => 'on_sl' },
|
|
|
|
{ oid => '2876', descr => 'deprecated, use <@ instead',
|
|
|
|
oprname => '@', oprleft => 'lseg', oprright => 'box', oprresult => 'bool',
|
|
|
|
oprcode => 'on_sb' },
|
|
|
|
{ oid => '2877', descr => 'deprecated, use @> instead',
|
|
|
|
oprname => '~', oprleft => '_aclitem', oprright => 'aclitem',
|
|
|
|
oprresult => 'bool', oprcode => 'aclcontains' },
|
|
|
|
|
|
|
|
# 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' },
|
|
|
|
|
|
|
|
# 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',
|
|
|
|
oprname => '=', oprcanmerge => 't', oprleft => 'record', oprright => 'record',
|
|
|
|
oprresult => 'bool', oprcom => '=(record,record)',
|
|
|
|
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',
|
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',
|
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' },
|
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
|
|
|
|
|
|
|
]
|