2000-01-05 18:31:08 +01:00
|
|
|
--
|
|
|
|
-- CREATE_OPERATOR
|
|
|
|
--
|
2010-11-23 21:27:50 +01:00
|
|
|
CREATE OPERATOR ## (
|
1997-04-06 08:07:13 +02:00
|
|
|
leftarg = path,
|
|
|
|
rightarg = path,
|
2018-08-15 18:05:46 +02:00
|
|
|
function = path_inter,
|
2010-11-23 21:27:50 +01:00
|
|
|
commutator = ##
|
1997-04-06 08:07:13 +02:00
|
|
|
);
|
2000-01-05 18:31:08 +01:00
|
|
|
CREATE OPERATOR @#@ (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8, -- prefix
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
1997-04-06 08:07:13 +02:00
|
|
|
);
|
2010-11-23 21:27:50 +01:00
|
|
|
CREATE OPERATOR #%# (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
leftarg = int8, -- fail, postfix is no longer supported
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
1997-04-06 08:07:13 +02:00
|
|
|
);
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
ERROR: operator right argument type must be specified
|
|
|
|
DETAIL: Postfix operators are not supported.
|
2018-02-27 18:13:14 +01:00
|
|
|
-- Test operator created above
|
2022-02-08 21:30:38 +01:00
|
|
|
SELECT @#@ 24;
|
|
|
|
?column?
|
|
|
|
--------------------------
|
|
|
|
620448401733239439360000
|
2018-02-27 18:13:14 +01:00
|
|
|
(1 row)
|
|
|
|
|
2003-11-21 23:32:49 +01:00
|
|
|
-- Test comments
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
COMMENT ON OPERATOR ###### (NONE, int4) IS 'bad prefix';
|
|
|
|
ERROR: operator does not exist: ###### integer
|
|
|
|
COMMENT ON OPERATOR ###### (int4, NONE) IS 'bad postfix';
|
|
|
|
ERROR: postfix operators are not supported
|
|
|
|
COMMENT ON OPERATOR ###### (int4, int8) IS 'bad infix';
|
|
|
|
ERROR: operator does not exist: integer ###### bigint
|
|
|
|
-- Check that DROP on a nonexistent op behaves sanely, too
|
|
|
|
DROP OPERATOR ###### (NONE, int4);
|
|
|
|
ERROR: operator does not exist: ###### integer
|
|
|
|
DROP OPERATOR ###### (int4, NONE);
|
|
|
|
ERROR: postfix operators are not supported
|
|
|
|
DROP OPERATOR ###### (int4, int8);
|
|
|
|
ERROR: operator does not exist: integer ###### bigint
|
|
|
|
-- => is disallowed as an operator name now
|
2013-07-03 16:48:26 +02:00
|
|
|
CREATE OPERATOR => (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
Allow named parameters to be specified using => in addition to :=
SQL has standardized on => as the use of to specify named parameters,
and we've wanted for many years to support the same syntax ourselves,
but this has been complicated by the possible use of => as an operator
name. In PostgreSQL 9.0, we began emitting a warning when an operator
named => was defined, and in PostgreSQL 9.2, we stopped shipping a
=>(text, text) operator as part of hstore. By the time the next major
version of PostgreSQL is released, => will have been deprecated for a
full five years, so hopefully there won't be too many people still
relying on it. We continue to support := for compatibility with
previous PostgreSQL releases.
Pavel Stehule, reviewed by Petr Jelinek, with a few documentation
tweaks by me.
2015-03-10 15:59:11 +01:00
|
|
|
ERROR: syntax error at or near "=>"
|
|
|
|
LINE 1: CREATE OPERATOR => (
|
|
|
|
^
|
Fix lexing of standard multi-character operators in edge cases.
Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)
and 865f14a2d (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.
The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:
1. If immediately followed by a comment or +-, >= <= <> would be given
the old precedence of Op rather than the correct new precedence;
2. If followed by a comment, != would be returned as Op rather than as
NOT_EQUAL, causing it not to be found at all;
3. If followed by a comment or +-, the => token for named arguments
would be lexed as Op, causing the argument to be mis-parsed as a
simple expression, usually causing an error.
Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.
Backpatch to 9.5 where the problem was introduced.
Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
2018-08-23 19:29:18 +02:00
|
|
|
-- lexing of <=, >=, <>, != has a number of edge cases
|
|
|
|
-- (=> is tested elsewhere)
|
|
|
|
-- this is legal because ! is not allowed in sql ops
|
|
|
|
CREATE OPERATOR !=- (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
Fix lexing of standard multi-character operators in edge cases.
Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)
and 865f14a2d (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.
The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:
1. If immediately followed by a comment or +-, >= <= <> would be given
the old precedence of Op rather than the correct new precedence;
2. If followed by a comment, != would be returned as Op rather than as
NOT_EQUAL, causing it not to be found at all;
3. If followed by a comment or +-, the => token for named arguments
would be lexed as Op, causing the argument to be mis-parsed as a
simple expression, usually causing an error.
Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.
Backpatch to 9.5 where the problem was introduced.
Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
2018-08-23 19:29:18 +02:00
|
|
|
);
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
SELECT !=- 10;
|
Fix lexing of standard multi-character operators in edge cases.
Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)
and 865f14a2d (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.
The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:
1. If immediately followed by a comment or +-, >= <= <> would be given
the old precedence of Op rather than the correct new precedence;
2. If followed by a comment, != would be returned as Op rather than as
NOT_EQUAL, causing it not to be found at all;
3. If followed by a comment or +-, the => token for named arguments
would be lexed as Op, causing the argument to be mis-parsed as a
simple expression, usually causing an error.
Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.
Backpatch to 9.5 where the problem was introduced.
Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
2018-08-23 19:29:18 +02:00
|
|
|
?column?
|
|
|
|
----------
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
3628800
|
Fix lexing of standard multi-character operators in edge cases.
Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)
and 865f14a2d (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.
The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:
1. If immediately followed by a comment or +-, >= <= <> would be given
the old precedence of Op rather than the correct new precedence;
2. If followed by a comment, != would be returned as Op rather than as
NOT_EQUAL, causing it not to be found at all;
3. If followed by a comment or +-, the => token for named arguments
would be lexed as Op, causing the argument to be mis-parsed as a
simple expression, usually causing an error.
Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.
Backpatch to 9.5 where the problem was introduced.
Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
2018-08-23 19:29:18 +02:00
|
|
|
(1 row)
|
|
|
|
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
-- postfix operators don't work anymore
|
|
|
|
SELECT 10 !=-;
|
|
|
|
ERROR: syntax error at or near ";"
|
|
|
|
LINE 1: SELECT 10 !=-;
|
|
|
|
^
|
Fix lexing of standard multi-character operators in edge cases.
Commits c6b3c939b (which fixed the precedence of >=, <=, <> operators)
and 865f14a2d (which added support for the standard => notation for
named arguments) created a class of lexer tokens which look like
multi-character operators but which have their own token IDs distinct
from Op. However, longest-match rules meant that following any of
these tokens with another operator character, as in (1<>-1), would
cause them to be incorrectly returned as Op.
The error here isn't immediately obvious, because the parser would
usually still find the correct operator via the Op token, but there
were more subtle problems:
1. If immediately followed by a comment or +-, >= <= <> would be given
the old precedence of Op rather than the correct new precedence;
2. If followed by a comment, != would be returned as Op rather than as
NOT_EQUAL, causing it not to be found at all;
3. If followed by a comment or +-, the => token for named arguments
would be lexed as Op, causing the argument to be mis-parsed as a
simple expression, usually causing an error.
Fix by explicitly checking for the operators in the {operator} code
block in addition to all the existing special cases there.
Backpatch to 9.5 where the problem was introduced.
Analysis and patch by me; review by Tom Lane.
Discussion: https://postgr.es/m/87va851ppl.fsf@news-spur.riddles.org.uk
2018-08-23 19:29:18 +02:00
|
|
|
-- make sure lexer returns != as <> even in edge cases
|
|
|
|
SELECT 2 !=/**/ 1, 2 !=/**/ 2;
|
|
|
|
?column? | ?column?
|
|
|
|
----------+----------
|
|
|
|
t | f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 2 !=-- comment to be removed by psql
|
|
|
|
1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DO $$ -- use DO to protect -- from psql
|
|
|
|
declare r boolean;
|
|
|
|
begin
|
|
|
|
execute $e$ select 2 !=-- comment
|
|
|
|
1 $e$ into r;
|
|
|
|
raise info 'r = %', r;
|
|
|
|
end;
|
|
|
|
$$;
|
|
|
|
INFO: r = t
|
|
|
|
-- check that <= etc. followed by more operator characters are returned
|
|
|
|
-- as the correct token with correct precedence
|
|
|
|
SELECT true<>-1 BETWEEN 1 AND 1; -- BETWEEN has prec. above <> but below Op
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT false<>/**/1 BETWEEN 1 AND 1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT false<=-1 BETWEEN 1 AND 1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT false>=-1 BETWEEN 1 AND 1;
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 2<=/**/3, 3>=/**/2, 2<>/**/3;
|
|
|
|
?column? | ?column? | ?column?
|
|
|
|
----------+----------+----------
|
|
|
|
t | t | t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT 3<=/**/2, 2>=/**/3, 2<>/**/2;
|
|
|
|
?column? | ?column? | ?column?
|
|
|
|
----------+----------+----------
|
|
|
|
f | f | f
|
|
|
|
(1 row)
|
|
|
|
|
2013-07-03 16:48:26 +02:00
|
|
|
-- Should fail. CREATE OPERATOR requires USAGE on SCHEMA
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE ROLE regress_rol_op1;
|
|
|
|
CREATE SCHEMA schema_op1;
|
|
|
|
GRANT USAGE ON SCHEMA schema_op1 TO PUBLIC;
|
|
|
|
REVOKE USAGE ON SCHEMA schema_op1 FROM regress_rol_op1;
|
|
|
|
SET ROLE regress_rol_op1;
|
|
|
|
CREATE OPERATOR schema_op1.#*# (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
|
|
|
ERROR: permission denied for schema schema_op1
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. SETOF type functions not allowed as argument (testing leftarg)
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
leftarg = SETOF int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
|
|
|
ERROR: SETOF type not allowed for operator argument
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. SETOF type functions not allowed as argument (testing rightarg)
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
rightarg = SETOF int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
|
|
|
ERROR: SETOF type not allowed for operator argument
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should work. Sample text-book case
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE OR REPLACE FUNCTION fn_op2(boolean, boolean)
|
|
|
|
RETURNS boolean AS $$
|
|
|
|
SELECT NULL::BOOLEAN;
|
|
|
|
$$ LANGUAGE sql IMMUTABLE;
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
LEFTARG = boolean,
|
|
|
|
RIGHTARG = boolean,
|
|
|
|
PROCEDURE = fn_op2,
|
|
|
|
COMMUTATOR = ===,
|
|
|
|
NEGATOR = !==,
|
|
|
|
RESTRICT = contsel,
|
|
|
|
JOIN = contjoinsel,
|
|
|
|
SORT1, SORT2, LTCMP, GTCMP, HASHES, MERGES
|
|
|
|
);
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. Invalid attribute
|
|
|
|
CREATE OPERATOR #@%# (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8,
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial,
|
2013-07-03 16:48:26 +02:00
|
|
|
invalid_att = int8
|
|
|
|
);
|
|
|
|
WARNING: operator attribute "invalid_att" not recognized
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
-- Should fail. At least rightarg should be mandatorily specified
|
2013-07-03 16:48:26 +02:00
|
|
|
CREATE OPERATOR #@%# (
|
2020-09-17 22:17:27 +02:00
|
|
|
procedure = factorial
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
ERROR: operator argument types must be specified
|
2013-07-03 16:48:26 +02:00
|
|
|
-- Should fail. Procedure should be mandatorily specified
|
|
|
|
CREATE OPERATOR #@%# (
|
Remove support for postfix (right-unary) operators.
This feature has been a thorn in our sides for a long time, causing
many grammatical ambiguity problems. It doesn't seem worth the
pain to continue to support it, so remove it.
There are some follow-on improvements we can make in the grammar,
but this commit only removes the bare minimum number of productions,
plus assorted backend support code.
Note that pg_dump and psql continue to have full support, since
they may be used against older servers. However, pg_dump warns
about postfix operators. There is also a check in pg_upgrade.
Documentation-wise, I (tgl) largely removed the "left unary"
terminology in favor of saying "prefix operator", which is
a more standard and IMO less confusing term.
I included a catversion bump, although no initial catalog data
changes here, to mark the boundary at which oprkind = 'r'
stopped being valid in pg_operator.
Mark Dilger, based on work by myself and Robert Haas;
review by John Naylor
Discussion: https://postgr.es/m/38ca86db-42ab-9b48-2902-337a0d6b8311@2ndquadrant.com
2020-09-18 01:38:05 +02:00
|
|
|
rightarg = int8
|
2013-07-03 16:48:26 +02:00
|
|
|
);
|
2018-08-15 18:05:46 +02:00
|
|
|
ERROR: operator function must be specified
|
2013-07-03 16:48:26 +02:00
|
|
|
-- Should fail. CREATE OPERATOR requires USAGE on TYPE
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE ROLE regress_rol_op3;
|
|
|
|
CREATE TYPE type_op3 AS ENUM ('new', 'open', 'closed');
|
|
|
|
CREATE FUNCTION fn_op3(type_op3, int8)
|
|
|
|
RETURNS int8 AS $$
|
|
|
|
SELECT NULL::int8;
|
|
|
|
$$ LANGUAGE sql IMMUTABLE;
|
|
|
|
REVOKE USAGE ON TYPE type_op3 FROM regress_rol_op3;
|
|
|
|
REVOKE USAGE ON TYPE type_op3 FROM PUBLIC; -- Need to do this so that regress_rol_op3 is not allowed USAGE via PUBLIC
|
|
|
|
SET ROLE regress_rol_op3;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
leftarg = type_op3,
|
|
|
|
rightarg = int8,
|
|
|
|
procedure = fn_op3
|
|
|
|
);
|
|
|
|
ERROR: permission denied for type type_op3
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. CREATE OPERATOR requires USAGE on TYPE (need to check separately for rightarg)
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE ROLE regress_rol_op4;
|
|
|
|
CREATE TYPE type_op4 AS ENUM ('new', 'open', 'closed');
|
|
|
|
CREATE FUNCTION fn_op4(int8, type_op4)
|
|
|
|
RETURNS int8 AS $$
|
|
|
|
SELECT NULL::int8;
|
|
|
|
$$ LANGUAGE sql IMMUTABLE;
|
|
|
|
REVOKE USAGE ON TYPE type_op4 FROM regress_rol_op4;
|
|
|
|
REVOKE USAGE ON TYPE type_op4 FROM PUBLIC; -- Need to do this so that regress_rol_op3 is not allowed USAGE via PUBLIC
|
|
|
|
SET ROLE regress_rol_op4;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
leftarg = int8,
|
|
|
|
rightarg = type_op4,
|
|
|
|
procedure = fn_op4
|
|
|
|
);
|
|
|
|
ERROR: permission denied for type type_op4
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. CREATE OPERATOR requires EXECUTE on function
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE ROLE regress_rol_op5;
|
|
|
|
CREATE TYPE type_op5 AS ENUM ('new', 'open', 'closed');
|
|
|
|
CREATE FUNCTION fn_op5(int8, int8)
|
|
|
|
RETURNS int8 AS $$
|
|
|
|
SELECT NULL::int8;
|
|
|
|
$$ LANGUAGE sql IMMUTABLE;
|
|
|
|
REVOKE EXECUTE ON FUNCTION fn_op5(int8, int8) FROM regress_rol_op5;
|
|
|
|
REVOKE EXECUTE ON FUNCTION fn_op5(int8, int8) FROM PUBLIC;-- Need to do this so that regress_rol_op3 is not allowed EXECUTE via PUBLIC
|
|
|
|
SET ROLE regress_rol_op5;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
leftarg = int8,
|
|
|
|
rightarg = int8,
|
|
|
|
procedure = fn_op5
|
|
|
|
);
|
|
|
|
ERROR: permission denied for function fn_op5
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. CREATE OPERATOR requires USAGE on return TYPE
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE ROLE regress_rol_op6;
|
|
|
|
CREATE TYPE type_op6 AS ENUM ('new', 'open', 'closed');
|
|
|
|
CREATE FUNCTION fn_op6(int8, int8)
|
|
|
|
RETURNS type_op6 AS $$
|
|
|
|
SELECT NULL::type_op6;
|
|
|
|
$$ LANGUAGE sql IMMUTABLE;
|
|
|
|
REVOKE USAGE ON TYPE type_op6 FROM regress_rol_op6;
|
|
|
|
REVOKE USAGE ON TYPE type_op6 FROM PUBLIC; -- Need to do this so that regress_rol_op3 is not allowed USAGE via PUBLIC
|
|
|
|
SET ROLE regress_rol_op6;
|
|
|
|
CREATE OPERATOR #*# (
|
|
|
|
leftarg = int8,
|
|
|
|
rightarg = int8,
|
|
|
|
procedure = fn_op6
|
|
|
|
);
|
|
|
|
ERROR: permission denied for type type_op6
|
|
|
|
ROLLBACK;
|
Extend ALTER OPERATOR to allow setting more optimization attributes.
Allow the COMMUTATOR, NEGATOR, MERGES, and HASHES attributes to be set
by ALTER OPERATOR. However, we don't allow COMMUTATOR/NEGATOR to be
changed once set, nor allow the MERGES/HASHES flags to be unset once
set. Changes like that might invalidate plans already made, and
dealing with the consequences seems like more trouble than it's worth.
The main use-case we foresee for this is to allow addition of missed
properties in extension update scripts, such as extending an existing
operator to support hashing. So only transitions from not-set to set
states seem very useful.
This patch also causes us to reject some incorrect cases that formerly
resulted in inconsistent catalog state, such as trying to set the
commutator of an operator to be some other operator that already has a
(different) commutator.
While at it, move the InvokeObjectPostCreateHook call for CREATE
OPERATOR to not occur until after we've fixed up commutator or negator
links as needed. The previous ordering could only be justified by
thinking of the OperatorUpd call as a kind of ALTER OPERATOR step;
but we don't call InvokeObjectPostAlterHook therein. It seems better
to let the hook see the final state of the operator object.
In the documentation, move the discussion of how to establish
commutator pairs from xoper.sgml to the CREATE OPERATOR ref page.
Tommy Pavlicek, reviewed and editorialized a bit by me
Discussion: https://postgr.es/m/CAEhP-W-vGVzf4udhR5M8Bdv88UYnPrhoSkj3ieR3QNrsGQoqdg@mail.gmail.com
2023-10-20 18:28:38 +02:00
|
|
|
-- Should fail. An operator cannot be its own negator.
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
leftarg = integer,
|
|
|
|
rightarg = integer,
|
|
|
|
procedure = int4eq,
|
|
|
|
negator = ===
|
|
|
|
);
|
|
|
|
ERROR: operator cannot be its own negator
|
|
|
|
ROLLBACK;
|
|
|
|
-- Should fail. An operator cannot be its own negator. Here we check that
|
|
|
|
-- this error is detected when replacing a shell operator.
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
-- create a shell operator for ===!!! by referencing it as a commutator
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
leftarg = integer,
|
|
|
|
rightarg = integer,
|
|
|
|
procedure = int4eq,
|
|
|
|
commutator = ===!!!
|
|
|
|
);
|
|
|
|
CREATE OPERATOR ===!!! (
|
|
|
|
leftarg = integer,
|
|
|
|
rightarg = integer,
|
|
|
|
procedure = int4ne,
|
|
|
|
negator = ===!!!
|
|
|
|
);
|
|
|
|
ERROR: operator cannot be its own negator
|
|
|
|
ROLLBACK;
|
|
|
|
-- test that we can't use part of an existing commutator or negator pair
|
|
|
|
-- as a commutator or negator
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
leftarg = integer,
|
|
|
|
rightarg = integer,
|
|
|
|
procedure = int4eq,
|
|
|
|
commutator = =
|
|
|
|
);
|
|
|
|
ERROR: commutator operator = is already the commutator of operator =
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
leftarg = integer,
|
|
|
|
rightarg = integer,
|
|
|
|
procedure = int4eq,
|
|
|
|
negator = <>
|
|
|
|
);
|
|
|
|
ERROR: negator operator <> is already the negator of operator =
|
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
We have a lot of code in which option names, which from the user's
viewpoint are logically keywords, are passed through the grammar as plain
identifiers, and then matched to string literals during command execution.
This approach avoids making words into lexer keywords unnecessarily. Some
places matched these strings using plain strcmp, some using pg_strcasecmp.
But the latter should be unnecessary since identifiers would have been
downcased on their way through the parser. Aside from any efficiency
concerns (probably not a big factor), the lack of consistency in this area
creates a hazard of subtle bugs due to different places coming to different
conclusions about whether two option names are the same or different.
Hence, standardize on using strcmp() to match any option names that are
expected to have been fed through the parser.
This does create a user-visible behavioral change, which is that while
formerly all of these would work:
alter table foo set (fillfactor = 50);
alter table foo set (FillFactor = 50);
alter table foo set ("fillfactor" = 50);
alter table foo set ("FillFactor" = 50);
now the last case will fail because that double-quoted identifier is
different from the others. However, none of our documentation says that
you can use a quoted identifier in such contexts at all, and we should
discourage doing so since it would break if we ever decide to parse such
constructs as true lexer keywords rather than poor man's substitutes.
So this shouldn't create a significant compatibility issue for users.
Daniel Gustafsson, reviewed by Michael Paquier, small changes by me
Discussion: https://postgr.es/m/29405B24-564E-476B-98C0-677A29805B84@yesql.se
2018-01-27 00:25:02 +01:00
|
|
|
-- invalid: non-lowercase quoted identifiers
|
|
|
|
CREATE OPERATOR ===
|
|
|
|
(
|
|
|
|
"Leftarg" = box,
|
|
|
|
"Rightarg" = box,
|
2018-08-15 17:01:39 +02:00
|
|
|
"Procedure" = area_equal_function,
|
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
We have a lot of code in which option names, which from the user's
viewpoint are logically keywords, are passed through the grammar as plain
identifiers, and then matched to string literals during command execution.
This approach avoids making words into lexer keywords unnecessarily. Some
places matched these strings using plain strcmp, some using pg_strcasecmp.
But the latter should be unnecessary since identifiers would have been
downcased on their way through the parser. Aside from any efficiency
concerns (probably not a big factor), the lack of consistency in this area
creates a hazard of subtle bugs due to different places coming to different
conclusions about whether two option names are the same or different.
Hence, standardize on using strcmp() to match any option names that are
expected to have been fed through the parser.
This does create a user-visible behavioral change, which is that while
formerly all of these would work:
alter table foo set (fillfactor = 50);
alter table foo set (FillFactor = 50);
alter table foo set ("fillfactor" = 50);
alter table foo set ("FillFactor" = 50);
now the last case will fail because that double-quoted identifier is
different from the others. However, none of our documentation says that
you can use a quoted identifier in such contexts at all, and we should
discourage doing so since it would break if we ever decide to parse such
constructs as true lexer keywords rather than poor man's substitutes.
So this shouldn't create a significant compatibility issue for users.
Daniel Gustafsson, reviewed by Michael Paquier, small changes by me
Discussion: https://postgr.es/m/29405B24-564E-476B-98C0-677A29805B84@yesql.se
2018-01-27 00:25:02 +01:00
|
|
|
"Commutator" = ===,
|
|
|
|
"Negator" = !==,
|
2018-08-15 17:01:39 +02:00
|
|
|
"Restrict" = area_restriction_function,
|
|
|
|
"Join" = area_join_function,
|
Avoid unnecessary use of pg_strcasecmp for already-downcased identifiers.
We have a lot of code in which option names, which from the user's
viewpoint are logically keywords, are passed through the grammar as plain
identifiers, and then matched to string literals during command execution.
This approach avoids making words into lexer keywords unnecessarily. Some
places matched these strings using plain strcmp, some using pg_strcasecmp.
But the latter should be unnecessary since identifiers would have been
downcased on their way through the parser. Aside from any efficiency
concerns (probably not a big factor), the lack of consistency in this area
creates a hazard of subtle bugs due to different places coming to different
conclusions about whether two option names are the same or different.
Hence, standardize on using strcmp() to match any option names that are
expected to have been fed through the parser.
This does create a user-visible behavioral change, which is that while
formerly all of these would work:
alter table foo set (fillfactor = 50);
alter table foo set (FillFactor = 50);
alter table foo set ("fillfactor" = 50);
alter table foo set ("FillFactor" = 50);
now the last case will fail because that double-quoted identifier is
different from the others. However, none of our documentation says that
you can use a quoted identifier in such contexts at all, and we should
discourage doing so since it would break if we ever decide to parse such
constructs as true lexer keywords rather than poor man's substitutes.
So this shouldn't create a significant compatibility issue for users.
Daniel Gustafsson, reviewed by Michael Paquier, small changes by me
Discussion: https://postgr.es/m/29405B24-564E-476B-98C0-677A29805B84@yesql.se
2018-01-27 00:25:02 +01:00
|
|
|
"Hashes",
|
|
|
|
"Merges"
|
|
|
|
);
|
|
|
|
WARNING: operator attribute "Leftarg" not recognized
|
|
|
|
WARNING: operator attribute "Rightarg" not recognized
|
|
|
|
WARNING: operator attribute "Procedure" not recognized
|
|
|
|
WARNING: operator attribute "Commutator" not recognized
|
|
|
|
WARNING: operator attribute "Negator" not recognized
|
|
|
|
WARNING: operator attribute "Restrict" not recognized
|
|
|
|
WARNING: operator attribute "Join" not recognized
|
|
|
|
WARNING: operator attribute "Hashes" not recognized
|
|
|
|
WARNING: operator attribute "Merges" not recognized
|
2018-08-15 18:05:46 +02:00
|
|
|
ERROR: operator function must be specified
|