2011-10-20 05:25:20 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* dropcmds.c
|
|
|
|
* handle various "DROP" operations
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2011-10-20 05:25:20 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2018-07-11 16:57:04 +02:00
|
|
|
* src/backend/commands/dropcmds.c
|
2011-10-20 05:25:20 +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"
|
|
|
|
#include "access/xact.h"
|
2011-10-20 05:25:20 +02:00
|
|
|
#include "catalog/dependency.h"
|
|
|
|
#include "catalog/namespace.h"
|
|
|
|
#include "catalog/objectaddress.h"
|
|
|
|
#include "catalog/pg_class.h"
|
2022-11-13 08:11:17 +01:00
|
|
|
#include "catalog/pg_namespace.h"
|
2011-11-18 03:31:29 +01:00
|
|
|
#include "catalog/pg_proc.h"
|
2011-10-20 05:25:20 +02:00
|
|
|
#include "commands/defrem.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "nodes/makefuncs.h"
|
|
|
|
#include "parser/parse_type.h"
|
2020-03-10 10:22:52 +01:00
|
|
|
#include "utils/acl.h"
|
2011-11-18 03:31:29 +01:00
|
|
|
#include "utils/builtins.h"
|
2017-11-30 14:46:13 +01:00
|
|
|
#include "utils/lsyscache.h"
|
2011-11-18 03:31:29 +01:00
|
|
|
#include "utils/syscache.h"
|
2011-10-20 05:25:20 +02:00
|
|
|
|
2014-01-23 18:40:29 +01:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
static void does_not_exist_skipping(ObjectType objtype,
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
Node *object);
|
|
|
|
static bool owningrel_does_not_exist_skipping(List *object,
|
2014-01-23 18:40:29 +01:00
|
|
|
const char **msg, char **name);
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
static bool schema_does_not_exist_skipping(List *object,
|
2014-01-23 18:40:29 +01:00
|
|
|
const char **msg, char **name);
|
|
|
|
static bool type_in_list_does_not_exist_skipping(List *typenames,
|
|
|
|
const char **msg, char **name);
|
|
|
|
|
2011-10-20 05:25:20 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Drop one or more objects.
|
|
|
|
*
|
|
|
|
* We don't currently handle all object types here. Relations, for example,
|
|
|
|
* require special handling, because (for example) indexes have additional
|
|
|
|
* locking requirements.
|
|
|
|
*
|
|
|
|
* We look up all the objects first, and then delete them in a single
|
|
|
|
* performMultipleDeletions() call. This avoids unnecessary DROP RESTRICT
|
|
|
|
* errors if there are dependencies between them.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RemoveObjects(DropStmt *stmt)
|
|
|
|
{
|
|
|
|
ObjectAddresses *objects;
|
|
|
|
ListCell *cell1;
|
|
|
|
|
|
|
|
objects = new_object_addresses();
|
|
|
|
|
|
|
|
foreach(cell1, stmt->objects)
|
|
|
|
{
|
|
|
|
ObjectAddress address;
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
Node *object = lfirst(cell1);
|
2011-10-20 05:25:20 +02:00
|
|
|
Relation relation = NULL;
|
|
|
|
Oid namespaceId;
|
|
|
|
|
|
|
|
/* Get an ObjectAddress for the object. */
|
|
|
|
address = get_object_address(stmt->removeType,
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
object,
|
2011-10-20 05:25:20 +02:00
|
|
|
&relation,
|
|
|
|
AccessExclusiveLock,
|
|
|
|
stmt->missing_ok);
|
|
|
|
|
2014-01-23 18:40:29 +01:00
|
|
|
/*
|
|
|
|
* Issue NOTICE if supplied object was not found. Note this is only
|
|
|
|
* relevant in the missing_ok case, because otherwise
|
|
|
|
* get_object_address would have thrown an error.
|
|
|
|
*/
|
2011-10-20 05:25:20 +02:00
|
|
|
if (!OidIsValid(address.objectId))
|
|
|
|
{
|
2014-01-23 18:40:29 +01:00
|
|
|
Assert(stmt->missing_ok);
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
does_not_exist_skipping(stmt->removeType, object);
|
2011-10-20 05:25:20 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
/*
|
|
|
|
* Although COMMENT ON FUNCTION, SECURITY LABEL ON FUNCTION, etc. are
|
|
|
|
* happy to operate on an aggregate as on any other function, we have
|
|
|
|
* historically not allowed this for DROP FUNCTION.
|
|
|
|
*/
|
|
|
|
if (stmt->removeType == OBJECT_FUNCTION)
|
|
|
|
{
|
2018-03-02 14:57:38 +01:00
|
|
|
if (get_func_prokind(address.objectId) == PROKIND_AGGREGATE)
|
2011-11-18 03:31:29 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is an aggregate function",
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
NameListToString(castNode(ObjectWithArgs, object)->objname)),
|
2011-11-18 03:31:29 +01:00
|
|
|
errhint("Use DROP AGGREGATE to drop aggregate functions.")));
|
|
|
|
}
|
|
|
|
|
2011-10-20 05:25:20 +02:00
|
|
|
/* Check permissions. */
|
|
|
|
namespaceId = get_object_namespace(&address);
|
|
|
|
if (!OidIsValid(namespaceId) ||
|
2022-11-13 08:11:17 +01:00
|
|
|
!object_ownercheck(NamespaceRelationId, namespaceId, GetUserId()))
|
2011-10-20 05:25:20 +02:00
|
|
|
check_object_ownership(GetUserId(), stmt->removeType, address,
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
object, relation);
|
2011-10-20 05:25:20 +02:00
|
|
|
|
Restrict the use of temporary namespace in two-phase transactions
Attempting to use a temporary table within a two-phase transaction is
forbidden for ages. However, there have been uncovered grounds for
a couple of other object types and commands which work on temporary
objects with two-phase commit. In short, trying to create, lock or drop
an object on a temporary schema should not be authorized within a
two-phase transaction, as it would cause its state to create
dependencies with other sessions, causing all sorts of side effects with
the existing session or other sessions spawned later on trying to use
the same temporary schema name.
Regression tests are added to cover all the grounds found, the original
report mentioned function creation, but monitoring closer there are many
other patterns with LOCK, DROP or CREATE EXTENSION which are involved.
One of the symptoms resulting in combining both is that the session
which used the temporary schema is not able to shut down completely,
waiting for being able to drop the temporary schema, something that it
cannot complete because of the two-phase transaction involved with
temporary objects. In this case the client is able to disconnect but
the session remains alive on the backend-side, potentially blocking
connection backend slots from being used. Other problems reported could
also involve server crashes.
This is back-patched down to v10, which is where 9b013dc has introduced
MyXactFlags, something that this patch relies on.
Reported-by: Alexey Bashtanov
Author: Michael Paquier
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/5d910e2e-0db8-ec06-dd5f-baec420513c3@imap.cc
Backpatch-through: 10
2019-01-18 01:21:44 +01:00
|
|
|
/*
|
|
|
|
* Make note if a temporary namespace has been accessed in this
|
|
|
|
* transaction.
|
|
|
|
*/
|
|
|
|
if (OidIsValid(namespaceId) && isTempNamespace(namespaceId))
|
|
|
|
MyXactFlags |= XACT_FLAGS_ACCESSEDTEMPNAMESPACE;
|
|
|
|
|
2011-10-20 05:25:20 +02:00
|
|
|
/* Release any relcache reference count, but keep lock until commit. */
|
|
|
|
if (relation)
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(relation, NoLock);
|
2011-10-20 05:25:20 +02:00
|
|
|
|
|
|
|
add_exact_object_address(&address, objects);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Here we really delete them. */
|
2012-01-26 15:24:54 +01:00
|
|
|
performMultipleDeletions(objects, stmt->behavior, 0);
|
2011-10-20 05:25:20 +02:00
|
|
|
|
|
|
|
free_object_addresses(objects);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-01-23 18:40:29 +01:00
|
|
|
* owningrel_does_not_exist_skipping
|
|
|
|
* Subroutine for RemoveObjects
|
|
|
|
*
|
|
|
|
* After determining that a specification for a rule or trigger returns that
|
|
|
|
* the specified object does not exist, test whether its owning relation, and
|
|
|
|
* its schema, exist or not; if they do, return false --- the trigger or rule
|
|
|
|
* itself is missing instead. If the owning relation or its schema do not
|
|
|
|
* exist, fill the error message format string and name, and return true.
|
|
|
|
*/
|
|
|
|
static bool
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
owningrel_does_not_exist_skipping(List *object, const char **msg, char **name)
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
List *parent_object;
|
2014-01-23 18:40:29 +01:00
|
|
|
RangeVar *parent_rel;
|
|
|
|
|
2022-07-13 05:03:47 +02:00
|
|
|
parent_object = list_copy_head(object, list_length(object) - 1);
|
2014-01-23 18:40:29 +01:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (schema_does_not_exist_skipping(parent_object, msg, name))
|
2014-01-23 18:40:29 +01:00
|
|
|
return true;
|
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
parent_rel = makeRangeVarFromNameList(parent_object);
|
2014-01-23 18:40:29 +01:00
|
|
|
|
|
|
|
if (!OidIsValid(RangeVarGetRelid(parent_rel, NoLock, true)))
|
|
|
|
{
|
|
|
|
*msg = gettext_noop("relation \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
*name = NameListToString(parent_object);
|
2014-01-23 18:40:29 +01:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* schema_does_not_exist_skipping
|
|
|
|
* Subroutine for RemoveObjects
|
|
|
|
*
|
|
|
|
* After determining that a specification for a schema-qualifiable object
|
|
|
|
* refers to an object that does not exist, test whether the specified schema
|
|
|
|
* exists or not. If no schema was specified, or if the schema does exist,
|
|
|
|
* return false -- the object itself is missing instead. If the specified
|
|
|
|
* schema does not exist, fill the error message format string and the
|
|
|
|
* specified schema name, and return true.
|
|
|
|
*/
|
|
|
|
static bool
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
schema_does_not_exist_skipping(List *object, const char **msg, char **name)
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
RangeVar *rel;
|
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
rel = makeRangeVarFromNameList(object);
|
2014-01-23 18:40:29 +01:00
|
|
|
|
|
|
|
if (rel->schemaname != NULL &&
|
|
|
|
!OidIsValid(LookupNamespaceNoError(rel->schemaname)))
|
|
|
|
{
|
|
|
|
*msg = gettext_noop("schema \"%s\" does not exist, skipping");
|
|
|
|
*name = rel->schemaname;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* type_in_list_does_not_exist_skipping
|
|
|
|
* Subroutine for RemoveObjects
|
|
|
|
*
|
|
|
|
* After determining that a specification for a function, cast, aggregate or
|
|
|
|
* operator returns that the specified object does not exist, test whether the
|
|
|
|
* involved datatypes, and their schemas, exist or not; if they do, return
|
|
|
|
* false --- the original object itself is missing instead. If the datatypes
|
|
|
|
* or schemas do not exist, fill the error message format string and the
|
|
|
|
* missing name, and return true.
|
|
|
|
*
|
|
|
|
* First parameter is a list of TypeNames.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
type_in_list_does_not_exist_skipping(List *typenames, const char **msg,
|
|
|
|
char **name)
|
|
|
|
{
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
foreach(l, typenames)
|
|
|
|
{
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
TypeName *typeName = lfirst_node(TypeName, l);
|
2014-01-23 18:40:29 +01:00
|
|
|
|
|
|
|
if (typeName != NULL)
|
|
|
|
{
|
|
|
|
if (!OidIsValid(LookupTypeNameOid(NULL, typeName, true)))
|
|
|
|
{
|
|
|
|
/* type doesn't exist, try to find why */
|
|
|
|
if (schema_does_not_exist_skipping(typeName->names, msg, name))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
*msg = gettext_noop("type \"%s\" does not exist, skipping");
|
|
|
|
*name = TypeNameToString(typeName);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* does_not_exist_skipping
|
|
|
|
* Subroutine for RemoveObjects
|
|
|
|
*
|
2011-10-20 05:25:20 +02:00
|
|
|
* Generate a NOTICE stating that the named object was not found, and is
|
|
|
|
* being skipped. This is only relevant when "IF EXISTS" is used; otherwise,
|
2014-01-23 18:40:29 +01:00
|
|
|
* get_object_address() in RemoveObjects would have thrown an ERROR.
|
2011-10-20 05:25:20 +02:00
|
|
|
*/
|
|
|
|
static void
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
does_not_exist_skipping(ObjectType objtype, Node *object)
|
2011-10-20 05:25:20 +02:00
|
|
|
{
|
|
|
|
const char *msg = NULL;
|
|
|
|
char *name = NULL;
|
2011-11-18 03:31:29 +01:00
|
|
|
char *args = NULL;
|
2011-10-20 05:25:20 +02:00
|
|
|
|
|
|
|
switch (objtype)
|
|
|
|
{
|
2016-05-27 17:03:18 +02:00
|
|
|
case OBJECT_ACCESS_METHOD:
|
|
|
|
msg = gettext_noop("access method \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2016-05-27 17:03:18 +02:00
|
|
|
break;
|
2011-10-20 05:25:20 +02:00
|
|
|
case OBJECT_TYPE:
|
|
|
|
case OBJECT_DOMAIN:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
TypeName *typ = castNode(TypeName, object);
|
2014-12-30 17:57:23 +01:00
|
|
|
|
|
|
|
if (!schema_does_not_exist_skipping(typ->names, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("type \"%s\" does not exist, skipping");
|
|
|
|
name = TypeNameToString(typ);
|
|
|
|
}
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_COLLATION:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("collation \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_CONVERSION:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("conversion \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_SCHEMA:
|
|
|
|
msg = gettext_noop("schema \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
case OBJECT_STATISTIC_EXT:
|
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
|
|
|
{
|
2017-05-14 16:54:47 +02:00
|
|
|
msg = gettext_noop("statistics object \"%s\" does not exist, skipping");
|
Implement multivariate n-distinct coefficients
Add support for explicitly declared statistic objects (CREATE
STATISTICS), allowing collection of statistics on more complex
combinations that individual table columns. Companion commands DROP
STATISTICS and ALTER STATISTICS ... OWNER TO / SET SCHEMA / RENAME are
added too. All this DDL has been designed so that more statistic types
can be added later on, such as multivariate most-common-values and
multivariate histograms between columns of a single table, leaving room
for permitting columns on multiple tables, too, as well as expressions.
This commit only adds support for collection of n-distinct coefficient
on user-specified sets of columns in a single table. This is useful to
estimate number of distinct groups in GROUP BY and DISTINCT clauses;
estimation errors there can cause over-allocation of memory in hashed
aggregates, for instance, so it's a worthwhile problem to solve. A new
special pseudo-type pg_ndistinct is used.
(num-distinct estimation was deemed sufficiently useful by itself that
this is worthwhile even if no further statistic types are added
immediately; so much so that another version of essentially the same
functionality was submitted by Kyotaro Horiguchi:
https://postgr.es/m/20150828.173334.114731693.horiguchi.kyotaro@lab.ntt.co.jp
though this commit does not use that code.)
Author: Tomas Vondra. Some code rework by Álvaro.
Reviewed-by: Dean Rasheed, David Rowley, Kyotaro Horiguchi, Jeff Janes,
Ideriha Takeshi
Discussion: https://postgr.es/m/543AFA15.4080608@fuzzy.cz
https://postgr.es/m/20170320190220.ixlaueanxegqd5gr@alvherre.pgsql
2017-03-24 18:06:10 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
|
|
|
}
|
|
|
|
break;
|
2011-10-20 05:25:20 +02:00
|
|
|
case OBJECT_TSPARSER:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("text search parser \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSDICTIONARY:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("text search dictionary \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSTEMPLATE:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("text search template \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSCONFIGURATION:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("text search configuration \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = NameListToString(castNode(List, object));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_EXTENSION:
|
|
|
|
msg = gettext_noop("extension \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_FUNCTION:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
ObjectWithArgs *owa = castNode(ObjectWithArgs, object);
|
2017-05-17 22:31:56 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(owa->objname, &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(owa->objargs, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("function %s(%s) does not exist, skipping");
|
|
|
|
name = NameListToString(owa->objname);
|
|
|
|
args = TypeNameListToString(owa->objargs);
|
|
|
|
}
|
|
|
|
break;
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2017-11-30 14:46:13 +01:00
|
|
|
case OBJECT_PROCEDURE:
|
|
|
|
{
|
|
|
|
ObjectWithArgs *owa = castNode(ObjectWithArgs, object);
|
|
|
|
|
|
|
|
if (!schema_does_not_exist_skipping(owa->objname, &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(owa->objargs, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("procedure %s(%s) does not exist, skipping");
|
|
|
|
name = NameListToString(owa->objname);
|
|
|
|
args = TypeNameListToString(owa->objargs);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case OBJECT_ROUTINE:
|
|
|
|
{
|
|
|
|
ObjectWithArgs *owa = castNode(ObjectWithArgs, object);
|
|
|
|
|
|
|
|
if (!schema_does_not_exist_skipping(owa->objname, &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(owa->objargs, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("routine %s(%s) does not exist, skipping");
|
|
|
|
name = NameListToString(owa->objname);
|
|
|
|
args = TypeNameListToString(owa->objargs);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_AGGREGATE:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
ObjectWithArgs *owa = castNode(ObjectWithArgs, object);
|
2017-05-17 22:31:56 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(owa->objname, &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(owa->objargs, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("aggregate %s(%s) does not exist, skipping");
|
|
|
|
name = NameListToString(owa->objname);
|
|
|
|
args = TypeNameListToString(owa->objargs);
|
|
|
|
}
|
|
|
|
break;
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_OPERATOR:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
ObjectWithArgs *owa = castNode(ObjectWithArgs, object);
|
2017-05-17 22:31:56 +02:00
|
|
|
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!schema_does_not_exist_skipping(owa->objname, &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(owa->objargs, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("operator %s does not exist, skipping");
|
|
|
|
name = NameListToString(owa->objname);
|
|
|
|
}
|
|
|
|
break;
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_LANGUAGE:
|
|
|
|
msg = gettext_noop("language \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
|
|
|
case OBJECT_CAST:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!type_in_list_does_not_exist_skipping(list_make1(linitial(castNode(List, object))), &msg, &name) &&
|
|
|
|
!type_in_list_does_not_exist_skipping(list_make1(lsecond(castNode(List, object))), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
/* XXX quote or no quote? */
|
|
|
|
msg = gettext_noop("cast from type %s to type %s does not exist, skipping");
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
name = TypeNameToString(linitial_node(TypeName, castNode(List, object)));
|
|
|
|
args = TypeNameToString(lsecond_node(TypeName, castNode(List, object)));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
2015-04-26 16:33:14 +02:00
|
|
|
case OBJECT_TRANSFORM:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!type_in_list_does_not_exist_skipping(list_make1(linitial(castNode(List, object))), &msg, &name))
|
2015-04-26 16:33:14 +02:00
|
|
|
{
|
2015-05-19 04:55:14 +02:00
|
|
|
msg = gettext_noop("transform for type %s language \"%s\" does not exist, skipping");
|
Improve castNode notation by introducing list-extraction-specific variants.
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
2017-04-10 19:51:29 +02:00
|
|
|
name = TypeNameToString(linitial_node(TypeName, castNode(List, object)));
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
args = strVal(lsecond(castNode(List, object)));
|
2015-04-26 16:33:14 +02:00
|
|
|
}
|
|
|
|
break;
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_TRIGGER:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!owningrel_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("trigger \"%s\" for relation \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = strVal(llast(castNode(List, object)));
|
2022-07-13 05:03:47 +02:00
|
|
|
args = NameListToString(list_copy_head(castNode(List, object),
|
|
|
|
list_length(castNode(List, object)) - 1));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case OBJECT_POLICY:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!owningrel_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
{
|
|
|
|
msg = gettext_noop("policy \"%s\" for relation \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = strVal(llast(castNode(List, object)));
|
2022-07-13 05:03:47 +02:00
|
|
|
args = NameListToString(list_copy_head(castNode(List, object),
|
|
|
|
list_length(castNode(List, object)) - 1));
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
}
|
|
|
|
break;
|
2012-07-18 16:16:16 +02:00
|
|
|
case OBJECT_EVENT_TRIGGER:
|
|
|
|
msg = gettext_noop("event trigger \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2012-07-18 16:16:16 +02:00
|
|
|
break;
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_RULE:
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
if (!owningrel_does_not_exist_skipping(castNode(List, object), &msg, &name))
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
|
|
|
msg = gettext_noop("rule \"%s\" for relation \"%s\" does not exist, skipping");
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
name = strVal(llast(castNode(List, object)));
|
2022-07-13 05:03:47 +02:00
|
|
|
args = NameListToString(list_copy_head(castNode(List, object),
|
|
|
|
list_length(castNode(List, object)) - 1));
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
|
|
|
case OBJECT_FDW:
|
|
|
|
msg = gettext_noop("foreign-data wrapper \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
|
|
|
case OBJECT_FOREIGN_SERVER:
|
|
|
|
msg = gettext_noop("server \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
|
|
|
case OBJECT_OPCLASS:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
List *opcname = list_copy_tail(castNode(List, object), 1);
|
2015-03-16 16:06:34 +01:00
|
|
|
|
|
|
|
if (!schema_does_not_exist_skipping(opcname, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("operator class \"%s\" does not exist for access method \"%s\", skipping");
|
|
|
|
name = NameListToString(opcname);
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
args = strVal(linitial(castNode(List, object)));
|
2015-03-16 16:06:34 +01:00
|
|
|
}
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
|
|
|
case OBJECT_OPFAMILY:
|
2014-01-23 18:40:29 +01:00
|
|
|
{
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
List *opfname = list_copy_tail(castNode(List, object), 1);
|
2015-03-16 16:06:34 +01:00
|
|
|
|
|
|
|
if (!schema_does_not_exist_skipping(opfname, &msg, &name))
|
|
|
|
{
|
|
|
|
msg = gettext_noop("operator family \"%s\" does not exist for access method \"%s\", skipping");
|
|
|
|
name = NameListToString(opfname);
|
Remove objname/objargs split for referring to objects
In simpler times, it might have worked to refer to all kinds of objects
by a list of name components and an optional argument list. But this
doesn't work for all objects, which has resulted in a collection of
hacks to place various other nodes types into these fields, which have
to be unpacked at the other end. This makes it also weird to represent
lists of such things in the grammar, because they would have to be lists
of singleton lists, to make the unpacking work consistently. The other
problem is that keeping separate name and args fields makes it awkward
to deal with lists of functions.
Change that by dropping the objargs field and have objname, renamed to
object, be a generic Node, which can then be flexibly assigned and
managed using the normal Node mechanisms. In many cases it will still
be a List of names, in some cases it will be a string Value, for types
it will be the existing Typename, for functions it will now use the
existing ObjectWithArgs node type. Some of the more obscure object
types still use somewhat arbitrary nested lists.
Reviewed-by: Jim Nasby <Jim.Nasby@BlueTreble.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
2016-11-12 18:00:00 +01:00
|
|
|
args = strVal(linitial(castNode(List, object)));
|
2015-03-16 16:06:34 +01:00
|
|
|
}
|
2014-01-23 18:40:29 +01:00
|
|
|
}
|
2011-11-18 03:31:29 +01:00
|
|
|
break;
|
2017-01-19 18:00:00 +01:00
|
|
|
case OBJECT_PUBLICATION:
|
|
|
|
msg = gettext_noop("publication \"%s\" does not exist, skipping");
|
2021-09-09 07:58:12 +02:00
|
|
|
name = strVal(object);
|
2017-01-19 18:00:00 +01:00
|
|
|
break;
|
2022-11-17 07:08:44 +01:00
|
|
|
|
|
|
|
case OBJECT_COLUMN:
|
|
|
|
case OBJECT_DATABASE:
|
|
|
|
case OBJECT_FOREIGN_TABLE:
|
|
|
|
case OBJECT_INDEX:
|
|
|
|
case OBJECT_MATVIEW:
|
|
|
|
case OBJECT_ROLE:
|
|
|
|
case OBJECT_SEQUENCE:
|
|
|
|
case OBJECT_SUBSCRIPTION:
|
|
|
|
case OBJECT_TABLE:
|
|
|
|
case OBJECT_TABLESPACE:
|
|
|
|
case OBJECT_VIEW:
|
|
|
|
/*
|
|
|
|
* These are handled elsewhere, so if someone gets here the code
|
|
|
|
* is probably wrong or should be revisited.
|
|
|
|
*/
|
|
|
|
elog(ERROR, "unsupported object type: %d", (int) objtype);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OBJECT_AMOP:
|
|
|
|
case OBJECT_AMPROC:
|
|
|
|
case OBJECT_ATTRIBUTE:
|
|
|
|
case OBJECT_DEFAULT:
|
|
|
|
case OBJECT_DEFACL:
|
|
|
|
case OBJECT_DOMCONSTRAINT:
|
|
|
|
case OBJECT_LARGEOBJECT:
|
|
|
|
case OBJECT_PARAMETER_ACL:
|
|
|
|
case OBJECT_PUBLICATION_NAMESPACE:
|
|
|
|
case OBJECT_PUBLICATION_REL:
|
|
|
|
case OBJECT_TABCONSTRAINT:
|
|
|
|
case OBJECT_USER_MAPPING:
|
|
|
|
/* These are currently not used or needed. */
|
|
|
|
elog(ERROR, "unsupported object type: %d", (int) objtype);
|
2011-10-20 05:25:20 +02:00
|
|
|
break;
|
2022-11-17 07:08:44 +01:00
|
|
|
|
|
|
|
/* no default, to let compiler warn about missing case */
|
2011-10-20 05:25:20 +02:00
|
|
|
}
|
2022-11-17 07:08:44 +01:00
|
|
|
if (!msg)
|
|
|
|
elog(ERROR, "unrecognized object type: %d", (int) objtype);
|
2011-10-20 05:25:20 +02:00
|
|
|
|
2011-11-18 03:31:29 +01:00
|
|
|
if (!args)
|
|
|
|
ereport(NOTICE, (errmsg(msg, name)));
|
|
|
|
else
|
|
|
|
ereport(NOTICE, (errmsg(msg, name, args)));
|
2011-10-20 05:25:20 +02:00
|
|
|
}
|