1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* pg_operator.c
|
1996-07-09 08:22:35 +02:00
|
|
|
* routines to support manipulation of the pg_operator relation
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/catalog/pg_operator.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* these routines moved here from commands/define.c and somewhat cleaned up.
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1998-04-27 06:08:07 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2019-01-21 19:18:20 +01:00
|
|
|
#include "access/table.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/xact.h"
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
#include "catalog/catalog.h"
|
2002-07-17 00:12:20 +02:00
|
|
|
#include "catalog/dependency.h"
|
1999-11-22 18:56:41 +01:00
|
|
|
#include "catalog/indexing.h"
|
2008-08-16 02:01:38 +02:00
|
|
|
#include "catalog/namespace.h"
|
2010-11-25 17:48:49 +01:00
|
|
|
#include "catalog/objectaccess.h"
|
2005-04-14 22:03:27 +02:00
|
|
|
#include "catalog/pg_namespace.h"
|
1998-04-27 06:08:07 +02:00
|
|
|
#include "catalog/pg_operator.h"
|
2005-04-14 03:38:22 +02:00
|
|
|
#include "catalog/pg_proc.h"
|
1998-04-27 06:08:07 +02:00
|
|
|
#include "catalog/pg_type.h"
|
|
|
|
#include "miscadmin.h"
|
2002-04-17 01:08:12 +02:00
|
|
|
#include "parser/parse_oper.h"
|
2002-04-27 05:45:03 +02:00
|
|
|
#include "utils/acl.h"
|
1998-04-27 06:08:07 +02:00
|
|
|
#include "utils/builtins.h"
|
2002-04-09 22:35:55 +02:00
|
|
|
#include "utils/lsyscache.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "utils/rel.h"
|
1998-04-27 06:08:07 +02:00
|
|
|
#include "utils/syscache.h"
|
|
|
|
|
1996-11-04 00:27:08 +01:00
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
static Oid OperatorGet(const char *operatorName,
|
2002-04-17 01:08:12 +02:00
|
|
|
Oid operatorNamespace,
|
2002-03-29 20:06:29 +01:00
|
|
|
Oid leftObjectId,
|
|
|
|
Oid rightObjectId,
|
|
|
|
bool *defined);
|
1999-04-11 04:30:59 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
static Oid OperatorLookup(List *operatorName,
|
|
|
|
Oid leftObjectId,
|
|
|
|
Oid rightObjectId,
|
|
|
|
bool *defined);
|
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
static Oid OperatorShellMake(const char *operatorName,
|
2002-04-17 01:08:12 +02:00
|
|
|
Oid operatorNamespace,
|
2002-03-29 20:06:29 +01:00
|
|
|
Oid leftTypeId,
|
|
|
|
Oid rightTypeId);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
static Oid get_other_operator(List *otherOp,
|
|
|
|
Oid otherLeftTypeId, Oid otherRightTypeId,
|
|
|
|
const char *operatorName, Oid operatorNamespace,
|
|
|
|
Oid leftTypeId, Oid rightTypeId,
|
|
|
|
bool isCommutator);
|
|
|
|
|
2001-10-22 21:34:13 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether a proposed operator name is legal
|
|
|
|
*
|
|
|
|
* This had better match the behavior of parser/scan.l!
|
|
|
|
*
|
|
|
|
* We need this because the parser is not smart enough to check that
|
|
|
|
* the arguments of CREATE OPERATOR's COMMUTATOR, NEGATOR, etc clauses
|
|
|
|
* are operator names rather than some other lexical entity.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
validOperatorName(const char *name)
|
|
|
|
{
|
|
|
|
size_t len = strlen(name);
|
|
|
|
|
|
|
|
/* Can't be empty or too long */
|
|
|
|
if (len == 0 || len >= NAMEDATALEN)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Can't contain any invalid characters */
|
|
|
|
/* Test string here should match op_chars in scan.l */
|
2003-07-21 03:59:11 +02:00
|
|
|
if (strspn(name, "~!@#^&|`?+-*/%<>=") != len)
|
2001-10-22 21:34:13 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Can't contain slash-star or dash-dash (comment starts) */
|
|
|
|
if (strstr(name, "/*") || strstr(name, "--"))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
2013-04-20 17:04:41 +02:00
|
|
|
* For SQL standard compatibility, '+' and '-' cannot be the last char of
|
2001-10-22 21:34:13 +02:00
|
|
|
* a multi-char operator unless the operator contains chars that are not
|
2013-04-20 17:04:41 +02:00
|
|
|
* in SQL operators. The idea is to lex '=-' as two operators, but not to
|
|
|
|
* forbid operator names like '?-' that could not be sequences of standard
|
2001-10-22 21:34:13 +02:00
|
|
|
* SQL operators.
|
|
|
|
*/
|
|
|
|
if (len > 1 &&
|
|
|
|
(name[len - 1] == '+' ||
|
|
|
|
name[len - 1] == '-'))
|
|
|
|
{
|
|
|
|
int ic;
|
|
|
|
|
|
|
|
for (ic = len - 2; ic >= 0; ic--)
|
|
|
|
{
|
2003-07-21 03:59:11 +02:00
|
|
|
if (strchr("~!@#^&|`?%", name[ic]))
|
2001-10-22 21:34:13 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ic < 0)
|
|
|
|
return false; /* nope, not valid */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* != isn't valid either, because parser will convert it to <> */
|
|
|
|
if (strcmp(name, "!=") == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
/*
|
|
|
|
* OperatorGet
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-04-17 01:08:12 +02:00
|
|
|
* finds an operator given an exact specification (name, namespace,
|
|
|
|
* left and right type IDs).
|
2001-06-01 04:41:36 +02:00
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* *defined is set true if defined (not a shell)
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
static Oid
|
2002-03-29 20:06:29 +01:00
|
|
|
OperatorGet(const char *operatorName,
|
2002-04-17 01:08:12 +02:00
|
|
|
Oid operatorNamespace,
|
2002-03-29 20:06:29 +01:00
|
|
|
Oid leftObjectId,
|
|
|
|
Oid rightObjectId,
|
|
|
|
bool *defined)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
HeapTuple tup;
|
2002-03-29 20:06:29 +01:00
|
|
|
Oid operatorObjectId;
|
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
tup = SearchSysCache4(OPERNAMENSP,
|
|
|
|
PointerGetDatum(operatorName),
|
|
|
|
ObjectIdGetDatum(leftObjectId),
|
|
|
|
ObjectIdGetDatum(rightObjectId),
|
|
|
|
ObjectIdGetDatum(operatorNamespace));
|
1999-04-11 04:30:59 +02:00
|
|
|
if (HeapTupleIsValid(tup))
|
|
|
|
{
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_operator oprform = (Form_pg_operator) GETSTRUCT(tup);
|
1999-05-25 18:15:34 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
operatorObjectId = oprform->oid;
|
|
|
|
*defined = RegProcedureIsValid(oprform->oprcode);
|
2002-04-17 01:08:12 +02:00
|
|
|
ReleaseSysCache(tup);
|
1999-04-11 04:30:59 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
operatorObjectId = InvalidOid;
|
|
|
|
*defined = false;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
return operatorObjectId;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* OperatorLookup
|
|
|
|
*
|
|
|
|
* looks up an operator given a possibly-qualified name and
|
|
|
|
* left and right type IDs.
|
|
|
|
*
|
2017-08-16 06:22:32 +02:00
|
|
|
* *defined is set true if defined (not a shell)
|
2002-04-17 01:08:12 +02:00
|
|
|
*/
|
|
|
|
static Oid
|
|
|
|
OperatorLookup(List *operatorName,
|
|
|
|
Oid leftObjectId,
|
|
|
|
Oid rightObjectId,
|
|
|
|
bool *defined)
|
|
|
|
{
|
|
|
|
Oid operatorObjectId;
|
2002-04-25 04:56:56 +02:00
|
|
|
RegProcedure oprcode;
|
2002-04-17 01:08:12 +02:00
|
|
|
|
2006-03-14 23:48:25 +01:00
|
|
|
operatorObjectId = LookupOperName(NULL, operatorName,
|
|
|
|
leftObjectId, rightObjectId,
|
|
|
|
true, -1);
|
2002-04-17 01:08:12 +02:00
|
|
|
if (!OidIsValid(operatorObjectId))
|
|
|
|
{
|
|
|
|
*defined = false;
|
|
|
|
return InvalidOid;
|
|
|
|
}
|
|
|
|
|
|
|
|
oprcode = get_opcode(operatorObjectId);
|
|
|
|
*defined = RegProcedureIsValid(oprcode);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-02-03 22:18:02 +01:00
|
|
|
return operatorObjectId;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
|
2002-03-29 20:06:29 +01:00
|
|
|
/*
|
|
|
|
* OperatorShellMake
|
|
|
|
* Make a "shell" entry for a not-yet-existing operator.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
static Oid
|
2002-03-29 20:06:29 +01:00
|
|
|
OperatorShellMake(const char *operatorName,
|
2002-04-17 01:08:12 +02:00
|
|
|
Oid operatorNamespace,
|
2002-03-29 20:06:29 +01:00
|
|
|
Oid leftTypeId,
|
|
|
|
Oid rightTypeId)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-10-22 21:34:13 +02:00
|
|
|
Relation pg_operator_desc;
|
|
|
|
Oid operatorObjectId;
|
1998-02-11 20:14:04 +01:00
|
|
|
int i;
|
1996-07-09 08:22:35 +02:00
|
|
|
HeapTuple tup;
|
|
|
|
Datum values[Natts_pg_operator];
|
2008-11-02 02:45:28 +01:00
|
|
|
bool nulls[Natts_pg_operator];
|
1998-04-01 17:35:33 +02:00
|
|
|
NameData oname;
|
1996-07-09 08:22:35 +02:00
|
|
|
TupleDesc tupDesc;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-10-22 21:34:13 +02:00
|
|
|
/*
|
|
|
|
* validate operator name
|
|
|
|
*/
|
|
|
|
if (!validOperatorName(operatorName))
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_NAME),
|
|
|
|
errmsg("\"%s\" is not a valid operator name",
|
|
|
|
operatorName)));
|
2001-10-22 21:34:13 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
/*
|
|
|
|
* open pg_operator
|
|
|
|
*/
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_operator_desc = table_open(OperatorRelationId, RowExclusiveLock);
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
tupDesc = pg_operator_desc->rd_att;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* initialize our *nulls and *values arrays
|
|
|
|
*/
|
|
|
|
for (i = 0; i < Natts_pg_operator; ++i)
|
|
|
|
{
|
2008-11-02 02:45:28 +01:00
|
|
|
nulls[i] = false;
|
1996-07-09 08:22:35 +02:00
|
|
|
values[i] = (Datum) NULL; /* redundant, but safe */
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2001-10-22 21:34:13 +02:00
|
|
|
* initialize values[] with the operator name and input data types. Note
|
1999-04-11 04:30:59 +02:00
|
|
|
* that oprcode is set to InvalidOid, indicating it's a shell.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
operatorObjectId = GetNewOidWithIndex(pg_operator_desc, OperatorOidIndexId,
|
|
|
|
Anum_pg_operator_oid);
|
|
|
|
values[Anum_pg_operator_oid - 1] = ObjectIdGetDatum(operatorObjectId);
|
1998-04-01 17:35:33 +02:00
|
|
|
namestrcpy(&oname, operatorName);
|
2011-06-16 23:03:58 +02:00
|
|
|
values[Anum_pg_operator_oprname - 1] = NameGetDatum(&oname);
|
|
|
|
values[Anum_pg_operator_oprnamespace - 1] = ObjectIdGetDatum(operatorNamespace);
|
|
|
|
values[Anum_pg_operator_oprowner - 1] = ObjectIdGetDatum(GetUserId());
|
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
|
|
|
values[Anum_pg_operator_oprkind - 1] = CharGetDatum(leftTypeId ? 'b' : 'l');
|
2011-06-16 23:03:58 +02:00
|
|
|
values[Anum_pg_operator_oprcanmerge - 1] = BoolGetDatum(false);
|
|
|
|
values[Anum_pg_operator_oprcanhash - 1] = BoolGetDatum(false);
|
|
|
|
values[Anum_pg_operator_oprleft - 1] = ObjectIdGetDatum(leftTypeId);
|
|
|
|
values[Anum_pg_operator_oprright - 1] = ObjectIdGetDatum(rightTypeId);
|
|
|
|
values[Anum_pg_operator_oprresult - 1] = ObjectIdGetDatum(InvalidOid);
|
|
|
|
values[Anum_pg_operator_oprcom - 1] = ObjectIdGetDatum(InvalidOid);
|
|
|
|
values[Anum_pg_operator_oprnegate - 1] = ObjectIdGetDatum(InvalidOid);
|
|
|
|
values[Anum_pg_operator_oprcode - 1] = ObjectIdGetDatum(InvalidOid);
|
|
|
|
values[Anum_pg_operator_oprrest - 1] = ObjectIdGetDatum(InvalidOid);
|
|
|
|
values[Anum_pg_operator_oprjoin - 1] = ObjectIdGetDatum(InvalidOid);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
/*
|
|
|
|
* create a new operator tuple
|
|
|
|
*/
|
2008-11-02 02:45:28 +01:00
|
|
|
tup = heap_form_tuple(tupDesc, values, nulls);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2001-10-22 21:34:13 +02:00
|
|
|
* insert our "shell" operator tuple
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
CatalogTupleInsert(pg_operator_desc, tup);
|
1999-11-22 18:56:41 +01:00
|
|
|
|
2002-07-17 00:12:20 +02:00
|
|
|
/* Add dependencies for the entry */
|
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
2021-08-17 20:29:22 +02:00
|
|
|
makeOperatorDependencies(tup, true, false);
|
2002-07-17 00:12:20 +02:00
|
|
|
|
1999-12-16 23:20:03 +01:00
|
|
|
heap_freetuple(tup);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2010-11-25 17:48:49 +01:00
|
|
|
/* Post creation hook for new shell operator */
|
2013-03-07 02:52:06 +01:00
|
|
|
InvokeObjectPostCreateHook(OperatorRelationId, operatorObjectId, 0);
|
2010-11-25 17:48:49 +01:00
|
|
|
|
2008-08-16 02:01:38 +02:00
|
|
|
/*
|
|
|
|
* Make sure the tuple is visible for subsequent lookups/updates.
|
|
|
|
*/
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* close the operator relation and return the oid.
|
|
|
|
*/
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_operator_desc, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-02-03 22:18:02 +01:00
|
|
|
return operatorObjectId;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
/*
|
|
|
|
* OperatorCreate
|
|
|
|
*
|
|
|
|
* "X" indicates an optional argument (i.e. one that can be NULL or 0)
|
|
|
|
* operatorName name for new operator
|
|
|
|
* operatorNamespace namespace for new operator
|
|
|
|
* leftTypeId X left type ID
|
|
|
|
* rightTypeId X right type ID
|
2008-08-16 02:01:38 +02:00
|
|
|
* procedureId procedure ID for operator
|
2002-04-17 01:08:12 +02:00
|
|
|
* commutatorName X commutator operator
|
|
|
|
* negatorName X negator operator
|
2008-08-16 02:01:38 +02:00
|
|
|
* restrictionId X restriction selectivity procedure ID
|
|
|
|
* joinId X join selectivity procedure ID
|
2006-12-23 01:43:13 +01:00
|
|
|
* canMerge merge join can be used with this operator
|
2002-04-17 01:08:12 +02:00
|
|
|
* canHash hash join can be used with this operator
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2008-08-16 02:01:38 +02:00
|
|
|
* The caller should have validated properties and permissions for the
|
|
|
|
* objects passed as OID references. We must handle the commutator and
|
|
|
|
* negator operator references specially, however, since those need not
|
|
|
|
* exist beforehand.
|
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
* This routine gets complicated because it allows the user to
|
|
|
|
* specify operators that do not exist. For example, if operator
|
|
|
|
* "op" is being defined, the negator operator "negop" and the
|
|
|
|
* commutator "commop" can also be defined without specifying
|
|
|
|
* any information other than their names. Since in order to
|
|
|
|
* add "op" to the PG_OPERATOR catalog, all the Oid's for these
|
|
|
|
* operators must be placed in the fields of "op", a forward
|
|
|
|
* declaration is done on the commutator and negator operators.
|
|
|
|
* This is called creating a shell, and its main effect is to
|
|
|
|
* create a tuple in the PG_OPERATOR catalog with minimal
|
|
|
|
* information about the operator (just its name and types).
|
|
|
|
* Forward declaration is used only for this purpose, it is
|
|
|
|
* not available to the user as it is for type definition.
|
|
|
|
*/
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
ObjectAddress
|
2002-04-17 01:08:12 +02:00
|
|
|
OperatorCreate(const char *operatorName,
|
|
|
|
Oid operatorNamespace,
|
|
|
|
Oid leftTypeId,
|
|
|
|
Oid rightTypeId,
|
2008-08-16 02:01:38 +02:00
|
|
|
Oid procedureId,
|
2002-04-17 01:08:12 +02:00
|
|
|
List *commutatorName,
|
|
|
|
List *negatorName,
|
2008-08-16 02:01:38 +02:00
|
|
|
Oid restrictionId,
|
|
|
|
Oid joinId,
|
2006-12-23 01:43:13 +01:00
|
|
|
bool canMerge,
|
|
|
|
bool canHash)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
Relation pg_operator_desc;
|
|
|
|
HeapTuple tup;
|
2015-12-31 23:37:31 +01:00
|
|
|
bool isUpdate;
|
2008-11-02 02:45:28 +01:00
|
|
|
bool nulls[Natts_pg_operator];
|
|
|
|
bool replaces[Natts_pg_operator];
|
1996-07-09 08:22:35 +02:00
|
|
|
Datum values[Natts_pg_operator];
|
|
|
|
Oid operatorObjectId;
|
1999-04-11 04:30:59 +02:00
|
|
|
bool operatorAlreadyDefined;
|
2002-04-17 01:08:12 +02:00
|
|
|
Oid operResultType;
|
|
|
|
Oid commutatorId,
|
2008-08-16 02:01:38 +02:00
|
|
|
negatorId;
|
1999-04-11 04:30:59 +02:00
|
|
|
bool selfCommutator = false;
|
1998-04-01 17:35:33 +02:00
|
|
|
NameData oname;
|
2002-04-17 01:08:12 +02:00
|
|
|
int i;
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
ObjectAddress address;
|
2002-03-29 20:06:29 +01:00
|
|
|
|
|
|
|
/*
|
2002-04-17 01:08:12 +02:00
|
|
|
* Sanity checks
|
2002-03-29 20:06:29 +01:00
|
|
|
*/
|
|
|
|
if (!validOperatorName(operatorName))
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_NAME),
|
|
|
|
errmsg("\"%s\" is not a valid operator name",
|
|
|
|
operatorName)));
|
2002-03-29 20:06:29 +01:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
if (!(OidIsValid(leftTypeId) && OidIsValid(rightTypeId)))
|
|
|
|
{
|
|
|
|
/* If it's not a binary op, these things mustn't be set: */
|
|
|
|
if (commutatorName)
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only binary operators can have commutators")));
|
2008-08-16 02:01:38 +02:00
|
|
|
if (OidIsValid(joinId))
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only binary operators can have join selectivity")));
|
2006-12-23 01:43:13 +01:00
|
|
|
if (canMerge)
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
2006-12-23 01:43:13 +01:00
|
|
|
errmsg("only binary operators can merge join")));
|
|
|
|
if (canHash)
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
2006-12-23 01:43:13 +01:00
|
|
|
errmsg("only binary operators can hash")));
|
2002-04-17 01:08:12 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2008-08-16 02:01:38 +02:00
|
|
|
operResultType = get_func_rettype(procedureId);
|
|
|
|
|
|
|
|
if (operResultType != BOOLOID)
|
|
|
|
{
|
|
|
|
/* If it's not a boolean op, these things mustn't be set: */
|
|
|
|
if (negatorName)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only boolean operators can have negators")));
|
|
|
|
if (OidIsValid(restrictionId))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only boolean operators can have restriction selectivity")));
|
|
|
|
if (OidIsValid(joinId))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only boolean operators can have join selectivity")));
|
|
|
|
if (canMerge)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only boolean operators can merge join")));
|
|
|
|
if (canHash)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("only boolean operators can hash")));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
operatorObjectId = OperatorGet(operatorName,
|
2002-04-17 01:08:12 +02:00
|
|
|
operatorNamespace,
|
2002-03-29 20:06:29 +01:00
|
|
|
leftTypeId,
|
|
|
|
rightTypeId,
|
1999-04-11 04:30:59 +02:00
|
|
|
&operatorAlreadyDefined);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-04-11 04:30:59 +02:00
|
|
|
if (operatorAlreadyDefined)
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_FUNCTION),
|
|
|
|
errmsg("operator %s already exists",
|
|
|
|
operatorName)));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1999-04-11 04:30:59 +02:00
|
|
|
/*
|
|
|
|
* At this point, if operatorObjectId is not InvalidOid then we are
|
2008-08-16 02:01:38 +02:00
|
|
|
* filling in a previously-created shell. Insist that the user own any
|
|
|
|
* such shell.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2008-08-16 02:01:38 +02:00
|
|
|
if (OidIsValid(operatorObjectId) &&
|
|
|
|
!pg_oper_ownercheck(operatorObjectId, GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_OPERATOR,
|
2008-08-16 02:01:38 +02:00
|
|
|
operatorName);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
1999-04-11 04:30:59 +02:00
|
|
|
* Set up the other operators. If they do not currently exist, create
|
|
|
|
* shells in order to get ObjectId's.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
if (commutatorName)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2002-04-17 01:08:12 +02:00
|
|
|
/* commutator has reversed arg types */
|
|
|
|
commutatorId = get_other_operator(commutatorName,
|
|
|
|
rightTypeId, leftTypeId,
|
|
|
|
operatorName, operatorNamespace,
|
|
|
|
leftTypeId, rightTypeId,
|
|
|
|
true);
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2008-08-16 02:01:38 +02:00
|
|
|
/* Permission check: must own other operator */
|
|
|
|
if (OidIsValid(commutatorId) &&
|
|
|
|
!pg_oper_ownercheck(commutatorId, GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_OPERATOR,
|
2008-08-16 02:01:38 +02:00
|
|
|
NameListToString(commutatorName));
|
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
/*
|
|
|
|
* self-linkage to this operator; will fix below. Note that only
|
|
|
|
* self-linkage for commutation makes sense.
|
|
|
|
*/
|
|
|
|
if (!OidIsValid(commutatorId))
|
|
|
|
selfCommutator = true;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
commutatorId = InvalidOid;
|
1999-04-11 04:30:59 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
if (negatorName)
|
|
|
|
{
|
|
|
|
/* negator has same arg types */
|
|
|
|
negatorId = get_other_operator(negatorName,
|
|
|
|
leftTypeId, rightTypeId,
|
|
|
|
operatorName, operatorNamespace,
|
|
|
|
leftTypeId, rightTypeId,
|
|
|
|
false);
|
2008-08-16 02:01:38 +02:00
|
|
|
|
|
|
|
/* Permission check: must own other operator */
|
|
|
|
if (OidIsValid(negatorId) &&
|
|
|
|
!pg_oper_ownercheck(negatorId, GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_OPERATOR,
|
2008-08-16 02:01:38 +02:00
|
|
|
NameListToString(negatorName));
|
2002-04-17 01:08:12 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
negatorId = InvalidOid;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2008-08-16 02:01:38 +02:00
|
|
|
/*
|
|
|
|
* set up values in the operator tuple
|
|
|
|
*/
|
|
|
|
|
|
|
|
for (i = 0; i < Natts_pg_operator; ++i)
|
|
|
|
{
|
|
|
|
values[i] = (Datum) NULL;
|
2008-11-02 02:45:28 +01:00
|
|
|
replaces[i] = true;
|
|
|
|
nulls[i] = false;
|
2008-08-16 02:01:38 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
namestrcpy(&oname, operatorName);
|
2011-06-16 23:03:58 +02:00
|
|
|
values[Anum_pg_operator_oprname - 1] = NameGetDatum(&oname);
|
|
|
|
values[Anum_pg_operator_oprnamespace - 1] = ObjectIdGetDatum(operatorNamespace);
|
|
|
|
values[Anum_pg_operator_oprowner - 1] = ObjectIdGetDatum(GetUserId());
|
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
|
|
|
values[Anum_pg_operator_oprkind - 1] = CharGetDatum(leftTypeId ? 'b' : 'l');
|
2011-06-16 23:03:58 +02:00
|
|
|
values[Anum_pg_operator_oprcanmerge - 1] = BoolGetDatum(canMerge);
|
|
|
|
values[Anum_pg_operator_oprcanhash - 1] = BoolGetDatum(canHash);
|
|
|
|
values[Anum_pg_operator_oprleft - 1] = ObjectIdGetDatum(leftTypeId);
|
|
|
|
values[Anum_pg_operator_oprright - 1] = ObjectIdGetDatum(rightTypeId);
|
|
|
|
values[Anum_pg_operator_oprresult - 1] = ObjectIdGetDatum(operResultType);
|
|
|
|
values[Anum_pg_operator_oprcom - 1] = ObjectIdGetDatum(commutatorId);
|
|
|
|
values[Anum_pg_operator_oprnegate - 1] = ObjectIdGetDatum(negatorId);
|
|
|
|
values[Anum_pg_operator_oprcode - 1] = ObjectIdGetDatum(procedureId);
|
|
|
|
values[Anum_pg_operator_oprrest - 1] = ObjectIdGetDatum(restrictionId);
|
|
|
|
values[Anum_pg_operator_oprjoin - 1] = ObjectIdGetDatum(joinId);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_operator_desc = table_open(OperatorRelationId, RowExclusiveLock);
|
1999-09-18 21:08:25 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
2008-08-16 02:01:38 +02:00
|
|
|
* If we are replacing an operator shell, update; else insert
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
if (operatorObjectId)
|
|
|
|
{
|
2015-12-31 23:37:31 +01:00
|
|
|
isUpdate = true;
|
|
|
|
|
2010-02-14 19:42:19 +01:00
|
|
|
tup = SearchSysCacheCopy1(OPEROID,
|
|
|
|
ObjectIdGetDatum(operatorObjectId));
|
2002-04-17 01:08:12 +02:00
|
|
|
if (!HeapTupleIsValid(tup))
|
2003-07-21 03:59:11 +02:00
|
|
|
elog(ERROR, "cache lookup failed for operator %u",
|
2002-04-17 01:08:12 +02:00
|
|
|
operatorObjectId);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
replaces[Anum_pg_operator_oid - 1] = false;
|
2008-11-02 02:45:28 +01:00
|
|
|
tup = heap_modify_tuple(tup,
|
2005-01-28 00:24:11 +01:00
|
|
|
RelationGetDescr(pg_operator_desc),
|
2002-04-17 01:08:12 +02:00
|
|
|
values,
|
|
|
|
nulls,
|
|
|
|
replaces);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_operator_desc, &tup->t_self, tup);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2015-12-31 23:37:31 +01:00
|
|
|
isUpdate = false;
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
operatorObjectId = GetNewOidWithIndex(pg_operator_desc,
|
|
|
|
OperatorOidIndexId,
|
|
|
|
Anum_pg_operator_oid);
|
|
|
|
values[Anum_pg_operator_oid - 1] = ObjectIdGetDatum(operatorObjectId);
|
|
|
|
|
2015-12-31 23:37:31 +01:00
|
|
|
tup = heap_form_tuple(RelationGetDescr(pg_operator_desc),
|
|
|
|
values, nulls);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
CatalogTupleInsert(pg_operator_desc, tup);
|
1999-11-22 18:56:41 +01:00
|
|
|
}
|
|
|
|
|
2002-07-17 00:12:20 +02:00
|
|
|
/* Add dependencies for the entry */
|
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
2021-08-17 20:29:22 +02:00
|
|
|
address = makeOperatorDependencies(tup, true, isUpdate);
|
2002-07-17 00:12:20 +02:00
|
|
|
|
2010-11-25 17:48:49 +01:00
|
|
|
/* Post creation hook for new operator */
|
2013-03-07 02:52:06 +01:00
|
|
|
InvokeObjectPostCreateHook(OperatorRelationId, operatorObjectId, 0);
|
2010-11-25 17:48:49 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_operator_desc, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
1999-04-11 04:30:59 +02:00
|
|
|
* If a commutator and/or negator link is provided, update the other
|
|
|
|
* operator(s) to point at this one, if they don't already have a link.
|
2007-11-07 13:24:24 +01:00
|
|
|
* This supports an alternative style of operator definition wherein the
|
1999-04-11 04:30:59 +02:00
|
|
|
* user first defines one operator without giving negator or commutator,
|
|
|
|
* then defines the other operator of the pair with the proper commutator
|
|
|
|
* or negator attribute. That style doesn't require creation of a shell,
|
|
|
|
* and it's the only style that worked right before Postgres version 6.5.
|
|
|
|
* This code also takes care of the situation where the new operator is
|
|
|
|
* its own commutator.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1999-04-11 04:30:59 +02:00
|
|
|
if (selfCommutator)
|
|
|
|
commutatorId = operatorObjectId;
|
|
|
|
|
|
|
|
if (OidIsValid(commutatorId) || OidIsValid(negatorId))
|
2016-03-25 17:33:16 +01:00
|
|
|
OperatorUpd(operatorObjectId, commutatorId, negatorId, false);
|
2012-12-24 00:25:03 +01:00
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
return address;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
/*
|
|
|
|
* Try to lookup another operator (commutator, etc)
|
|
|
|
*
|
|
|
|
* If not found, check to see if it is exactly the operator we are trying
|
|
|
|
* to define; if so, return InvalidOid. (Note that this case is only
|
|
|
|
* sensible for a commutator, so we error out otherwise.) If it is not
|
|
|
|
* the same operator, create a shell operator.
|
|
|
|
*/
|
|
|
|
static Oid
|
|
|
|
get_other_operator(List *otherOp, Oid otherLeftTypeId, Oid otherRightTypeId,
|
|
|
|
const char *operatorName, Oid operatorNamespace,
|
|
|
|
Oid leftTypeId, Oid rightTypeId, bool isCommutator)
|
|
|
|
{
|
|
|
|
Oid other_oid;
|
|
|
|
bool otherDefined;
|
|
|
|
char *otherName;
|
|
|
|
Oid otherNamespace;
|
2002-04-27 05:45:03 +02:00
|
|
|
AclResult aclresult;
|
2002-04-17 01:08:12 +02:00
|
|
|
|
|
|
|
other_oid = OperatorLookup(otherOp,
|
|
|
|
otherLeftTypeId,
|
|
|
|
otherRightTypeId,
|
|
|
|
&otherDefined);
|
|
|
|
|
|
|
|
if (OidIsValid(other_oid))
|
|
|
|
{
|
|
|
|
/* other op already in catalogs */
|
|
|
|
return other_oid;
|
|
|
|
}
|
|
|
|
|
|
|
|
otherNamespace = QualifiedNameGetCreationNamespace(otherOp,
|
|
|
|
&otherName);
|
|
|
|
|
|
|
|
if (strcmp(otherName, operatorName) == 0 &&
|
|
|
|
otherNamespace == operatorNamespace &&
|
|
|
|
otherLeftTypeId == leftTypeId &&
|
|
|
|
otherRightTypeId == rightTypeId)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* self-linkage to this operator; caller will fix later. Note that
|
|
|
|
* only self-linkage for commutation makes sense.
|
|
|
|
*/
|
|
|
|
if (!isCommutator)
|
2003-07-21 03:59:11 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
|
|
|
|
errmsg("operator cannot be its own negator or sort operator")));
|
2002-04-17 01:08:12 +02:00
|
|
|
return InvalidOid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* not in catalogs, different from operator, so make shell */
|
2002-04-27 05:45:03 +02:00
|
|
|
|
|
|
|
aclresult = pg_namespace_aclcheck(otherNamespace, GetUserId(),
|
|
|
|
ACL_CREATE);
|
|
|
|
if (aclresult != ACLCHECK_OK)
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(aclresult, OBJECT_SCHEMA,
|
2003-08-01 02:15:26 +02:00
|
|
|
get_namespace_name(otherNamespace));
|
2002-04-27 05:45:03 +02:00
|
|
|
|
2002-04-17 01:08:12 +02:00
|
|
|
other_oid = OperatorShellMake(otherName,
|
|
|
|
otherNamespace,
|
|
|
|
otherLeftTypeId,
|
|
|
|
otherRightTypeId);
|
|
|
|
return other_oid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
1996-07-09 08:22:35 +02:00
|
|
|
* OperatorUpd
|
|
|
|
*
|
|
|
|
* For a given operator, look up its negator and commutator operators.
|
2016-03-25 17:33:16 +01:00
|
|
|
* When isDelete is false, update their negator and commutator fields to
|
|
|
|
* point back to the given operator; when isDelete is true, update those
|
|
|
|
* fields to no longer point back to the given operator.
|
|
|
|
*
|
|
|
|
* The !isDelete case solves a problem for users who need to insert two new
|
|
|
|
* operators that are the negator or commutator of each other, while the
|
|
|
|
* isDelete case is needed so as not to leave dangling OID links behind
|
|
|
|
* after dropping an operator.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2016-03-25 17:33:16 +01:00
|
|
|
void
|
|
|
|
OperatorUpd(Oid baseId, Oid commId, Oid negId, bool isDelete)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
Relation pg_operator_desc;
|
|
|
|
HeapTuple tup;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-01-18 00:57:48 +01:00
|
|
|
/*
|
2016-03-25 17:33:16 +01:00
|
|
|
* If we're making an operator into its own commutator, then we need a
|
|
|
|
* command-counter increment here, since we've just inserted the tuple
|
|
|
|
* we're about to update. But when we're dropping an operator, we can
|
|
|
|
* skip this because we're at the beginning of the command.
|
2000-01-18 00:57:48 +01:00
|
|
|
*/
|
2016-03-25 17:33:16 +01:00
|
|
|
if (!isDelete)
|
|
|
|
CommandCounterIncrement();
|
2000-01-18 00:57:48 +01:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* Open the relation. */
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_operator_desc = table_open(OperatorRelationId, RowExclusiveLock);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* Get a writable copy of the commutator's tuple. */
|
|
|
|
if (OidIsValid(commId))
|
|
|
|
tup = SearchSysCacheCopy1(OPEROID, ObjectIdGetDatum(commId));
|
|
|
|
else
|
|
|
|
tup = NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* Update the commutator's tuple if need be. */
|
|
|
|
if (HeapTupleIsValid(tup))
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2016-03-25 17:33:16 +01:00
|
|
|
Form_pg_operator t = (Form_pg_operator) GETSTRUCT(tup);
|
|
|
|
bool update_commutator = false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Out of due caution, we only change the commutator's oprcom field if
|
|
|
|
* it has the exact value we expected: InvalidOid when creating an
|
|
|
|
* operator, or baseId when dropping one.
|
|
|
|
*/
|
|
|
|
if (isDelete && t->oprcom == baseId)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2016-03-25 17:33:16 +01:00
|
|
|
t->oprcom = InvalidOid;
|
|
|
|
update_commutator = true;
|
|
|
|
}
|
|
|
|
else if (!isDelete && !OidIsValid(t->oprcom))
|
|
|
|
{
|
|
|
|
t->oprcom = baseId;
|
|
|
|
update_commutator = true;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* If any columns were found to need modification, update tuple. */
|
|
|
|
if (update_commutator)
|
|
|
|
{
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_operator_desc, &tup->t_self, tup);
|
2016-03-25 17:33:16 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Do CCI to make the updated tuple visible. We must do this in
|
|
|
|
* case the commutator is also the negator. (Which would be a
|
|
|
|
* logic error on the operator definer's part, but that's not a
|
|
|
|
* good reason to fail here.) We would need a CCI anyway in the
|
|
|
|
* deletion case for a self-commutator with no negator.
|
|
|
|
*/
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/*
|
|
|
|
* Similarly find and update the negator, if any.
|
|
|
|
*/
|
|
|
|
if (OidIsValid(negId))
|
|
|
|
tup = SearchSysCacheCopy1(OPEROID, ObjectIdGetDatum(negId));
|
|
|
|
else
|
|
|
|
tup = NULL;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
if (HeapTupleIsValid(tup))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2016-03-25 17:33:16 +01:00
|
|
|
Form_pg_operator t = (Form_pg_operator) GETSTRUCT(tup);
|
|
|
|
bool update_negator = false;
|
2002-04-17 01:08:12 +02:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/*
|
|
|
|
* Out of due caution, we only change the negator's oprnegate field if
|
|
|
|
* it has the exact value we expected: InvalidOid when creating an
|
|
|
|
* operator, or baseId when dropping one.
|
|
|
|
*/
|
|
|
|
if (isDelete && t->oprnegate == baseId)
|
|
|
|
{
|
|
|
|
t->oprnegate = InvalidOid;
|
|
|
|
update_negator = true;
|
|
|
|
}
|
|
|
|
else if (!isDelete && !OidIsValid(t->oprnegate))
|
|
|
|
{
|
|
|
|
t->oprnegate = baseId;
|
|
|
|
update_negator = true;
|
|
|
|
}
|
1999-11-22 18:56:41 +01:00
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* If any columns were found to need modification, update tuple. */
|
|
|
|
if (update_negator)
|
|
|
|
{
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_operator_desc, &tup->t_self, tup);
|
2016-03-25 17:33:16 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the deletion case, do CCI to make the updated tuple visible.
|
|
|
|
* We must do this in case the operator is its own negator. (Which
|
|
|
|
* would be a logic error on the operator definer's part, but
|
|
|
|
* that's not a good reason to fail here.)
|
|
|
|
*/
|
|
|
|
if (isDelete)
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2016-03-25 17:33:16 +01:00
|
|
|
/* Close relation and release catalog lock. */
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_operator_desc, RowExclusiveLock);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2002-07-17 00:12:20 +02:00
|
|
|
|
|
|
|
/*
|
2015-12-31 23:37:31 +01:00
|
|
|
* Create dependencies for an operator (either a freshly inserted
|
|
|
|
* complete operator, a new shell operator, a just-updated shell,
|
|
|
|
* or an operator that's being modified by ALTER OPERATOR).
|
2002-07-17 00:12:20 +02:00
|
|
|
*
|
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
2021-08-17 20:29:22 +02:00
|
|
|
* makeExtensionDep should be true when making a new operator or
|
|
|
|
* replacing a shell, false for ALTER OPERATOR. Passing false
|
|
|
|
* will prevent any change in the operator's extension membership.
|
|
|
|
*
|
2002-07-18 18:47:26 +02:00
|
|
|
* NB: the OidIsValid tests in this routine are necessary, in case
|
2002-07-17 00:12:20 +02:00
|
|
|
* the given operator is a shell.
|
|
|
|
*/
|
2015-12-31 23:37:31 +01:00
|
|
|
ObjectAddress
|
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
2021-08-17 20:29:22 +02:00
|
|
|
makeOperatorDependencies(HeapTuple tuple,
|
|
|
|
bool makeExtensionDep,
|
|
|
|
bool isUpdate)
|
2002-07-17 00:12:20 +02:00
|
|
|
{
|
|
|
|
Form_pg_operator oper = (Form_pg_operator) GETSTRUCT(tuple);
|
|
|
|
ObjectAddress myself,
|
|
|
|
referenced;
|
2020-09-05 14:33:53 +02:00
|
|
|
ObjectAddresses *addrs;
|
2002-07-17 00:12:20 +02:00
|
|
|
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(myself, OperatorRelationId, oper->oid);
|
2002-07-17 00:12:20 +02:00
|
|
|
|
2011-08-22 16:55:47 +02:00
|
|
|
/*
|
2015-12-31 23:37:31 +01:00
|
|
|
* If we are updating the operator, delete any existing entries, except
|
2011-08-22 16:55:47 +02:00
|
|
|
* for extension membership which should remain the same.
|
|
|
|
*/
|
2015-12-31 23:37:31 +01:00
|
|
|
if (isUpdate)
|
|
|
|
{
|
|
|
|
deleteDependencyRecordsFor(myself.classId, myself.objectId, true);
|
|
|
|
deleteSharedDependencyRecordsFor(myself.classId, myself.objectId, 0);
|
|
|
|
}
|
2002-07-17 00:12:20 +02:00
|
|
|
|
2020-09-05 14:33:53 +02:00
|
|
|
addrs = new_object_addresses();
|
|
|
|
|
2002-07-18 18:47:26 +02:00
|
|
|
/* Dependency on namespace */
|
|
|
|
if (OidIsValid(oper->oprnamespace))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, NamespaceRelationId, oper->oprnamespace);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-18 18:47:26 +02:00
|
|
|
}
|
|
|
|
|
2002-07-17 00:12:20 +02:00
|
|
|
/* Dependency on left type */
|
|
|
|
if (OidIsValid(oper->oprleft))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, TypeRelationId, oper->oprleft);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Dependency on right type */
|
|
|
|
if (OidIsValid(oper->oprright))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, TypeRelationId, oper->oprright);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Dependency on result type */
|
|
|
|
if (OidIsValid(oper->oprresult))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, TypeRelationId, oper->oprresult);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: we do not consider the operator to depend on the associated
|
2006-12-23 01:43:13 +01:00
|
|
|
* operators oprcom and oprnegate. We would not want to delete this
|
|
|
|
* operator if those go away, but only reset the link fields; which is not
|
|
|
|
* a function that the dependency code can presently handle. (Something
|
|
|
|
* could perhaps be done with objectSubId though.) For now, it's okay to
|
|
|
|
* let those links dangle if a referenced operator is removed.
|
2002-07-17 00:12:20 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Dependency on implementation function */
|
|
|
|
if (OidIsValid(oper->oprcode))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, ProcedureRelationId, oper->oprcode);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Dependency on restriction selectivity function */
|
|
|
|
if (OidIsValid(oper->oprrest))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, ProcedureRelationId, oper->oprrest);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Dependency on join selectivity function */
|
|
|
|
if (OidIsValid(oper->oprjoin))
|
|
|
|
{
|
2020-07-01 10:03:50 +02:00
|
|
|
ObjectAddressSet(referenced, ProcedureRelationId, oper->oprjoin);
|
2020-09-05 14:33:53 +02:00
|
|
|
add_exact_object_address(&referenced, addrs);
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|
2005-07-07 22:40:02 +02:00
|
|
|
|
2020-09-05 14:33:53 +02:00
|
|
|
record_object_address_dependencies(&myself, addrs, DEPENDENCY_NORMAL);
|
|
|
|
free_object_addresses(addrs);
|
|
|
|
|
2005-07-07 22:40:02 +02:00
|
|
|
/* Dependency on owner */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
recordDependencyOnOwner(OperatorRelationId, oper->oid,
|
2005-07-07 22:40:02 +02:00
|
|
|
oper->oprowner);
|
2011-02-08 22:08:41 +01:00
|
|
|
|
|
|
|
/* Dependency on extension */
|
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
2021-08-17 20:29:22 +02:00
|
|
|
if (makeExtensionDep)
|
|
|
|
recordDependencyOnCurrentExtension(&myself, true);
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
|
|
|
|
return myself;
|
2002-07-17 00:12:20 +02:00
|
|
|
}
|