2002-03-26 20:17:02 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* namespace.h
|
|
|
|
* prototypes for functions in backend/catalog/namespace.c
|
|
|
|
*
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2002-03-26 20:17:02 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/catalog/namespace.h
|
2002-03-26 20:17:02 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef NAMESPACE_H
|
|
|
|
#define NAMESPACE_H
|
|
|
|
|
|
|
|
#include "nodes/primnodes.h"
|
2011-07-09 04:19:30 +02:00
|
|
|
#include "storage/lock.h"
|
2024-03-03 18:38:22 +01:00
|
|
|
#include "storage/procnumber.h"
|
2002-03-26 20:17:02 +01:00
|
|
|
|
|
|
|
|
2002-04-06 08:59:25 +02:00
|
|
|
/*
|
|
|
|
* This structure holds a list of possible functions or operators
|
|
|
|
* found by namespace lookup. Each function/operator is identified
|
|
|
|
* by OID and by argument types; the list must be pruned by type
|
|
|
|
* resolution rules that are embodied in the parser, not here.
|
2008-12-18 19:20:35 +01:00
|
|
|
* See FuncnameGetCandidates's comments for more info.
|
2002-04-06 08:59:25 +02:00
|
|
|
*/
|
|
|
|
typedef struct _FuncCandidateList
|
|
|
|
{
|
|
|
|
struct _FuncCandidateList *next;
|
|
|
|
int pathpos; /* for internal use of namespace lookup */
|
|
|
|
Oid oid; /* the function or operator's OID */
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
int nominalnargs; /* either pronargs or length(proallargtypes) */
|
2002-04-25 04:56:56 +02:00
|
|
|
int nargs; /* number of arg types returned */
|
2008-07-16 03:30:23 +02:00
|
|
|
int nvargs; /* number of args to become variadic array */
|
2008-12-18 19:20:35 +01:00
|
|
|
int ndargs; /* number of defaulted args */
|
2009-10-08 04:39:25 +02:00
|
|
|
int *argnumbers; /* args' positional indexes, if named call */
|
2015-02-20 06:11:42 +01:00
|
|
|
Oid args[FLEXIBLE_ARRAY_MEMBER]; /* arg types */
|
|
|
|
} *FuncCandidateList;
|
2002-04-06 08:59:25 +02:00
|
|
|
|
Avoid failure if autovacuum tries to access a just-dropped temp namespace.
Such an access became possible when commit 246a6c8f7 added more
aggressive cleanup of orphaned temp relations by autovacuum.
Since autovacuum's snapshot might be slightly stale, it could
attempt to access an already-dropped temp namespace, resulting in
an assertion failure or null-pointer dereference. (In practice,
since we don't drop temp namespaces automatically but merely
recycle them, this situation could only arise if a superuser does
a manual drop of a temp namespace. Still, that should be allowed.)
The core of the bug, IMO, is that isTempNamespaceInUse and its callers
failed to think hard about whether to treat "temp namespace isn't there"
differently from "temp namespace isn't in use". In hopes of forestalling
future mistakes of the same ilk, replace that function with a new one
checkTempNamespaceStatus, which makes the same tests but returns a
three-way enum rather than just a bool. isTempNamespaceInUse is gone
entirely in HEAD; but just in case some external code is relying on it,
keep it in the back branches, as a bug-compatible wrapper around the
new function.
Per report originally from Prabhat Kumar Sahu, investigated by Mahendra
Singh and Michael Paquier; the final form of the patch is my fault.
This replaces the failed fix attempt in a052f6cbb.
Backpatch as far as v11, as 246a6c8f7 was.
Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com
2020-02-29 02:28:34 +01:00
|
|
|
/*
|
|
|
|
* Result of checkTempNamespaceStatus
|
|
|
|
*/
|
|
|
|
typedef enum TempNamespaceStatus
|
|
|
|
{
|
|
|
|
TEMP_NAMESPACE_NOT_TEMP, /* nonexistent, or non-temp namespace */
|
|
|
|
TEMP_NAMESPACE_IDLE, /* exists, belongs to no active session */
|
|
|
|
TEMP_NAMESPACE_IN_USE, /* belongs to some active session */
|
|
|
|
} TempNamespaceStatus;
|
|
|
|
|
2007-03-23 20:53:52 +01:00
|
|
|
/*
|
2023-08-01 02:04:47 +02:00
|
|
|
* Structure for xxxSearchPathMatcher functions
|
Improve performance of "simple expressions" in PL/pgSQL.
For relatively simple expressions (say, "x + 1" or "x > 0"), plpgsql's
management overhead exceeds the cost of evaluating the expression.
This patch substantially improves that situation, providing roughly
2X speedup for such trivial expressions.
First, add infrastructure in the plancache to allow fast re-validation
of cached plans that contain no table access, and hence need no locks.
Teach plpgsql to use this infrastructure for expressions that it's
already deemed "simple" (which in particular will never contain table
references).
The fast path still requires checking that search_path hasn't changed,
so provide a fast path for OverrideSearchPathMatchesCurrent by
counting changes that have occurred to the active search path in the
current session. This is simplistic but seems enough for now, seeing
that PushOverrideSearchPath is not used in any performance-critical
cases.
Second, manage the refcounts on simple expressions' cached plans using
a transaction-lifespan resource owner, so that we only need to take
and release an expression's refcount once per transaction not once per
expression evaluation. The management of this resource owner exactly
parallels the existing management of plpgsql's simple-expression EState.
Add some regression tests covering this area, in particular verifying
that expression caching doesn't break semantics for search_path changes.
Patch by me, but it owes something to previous work by Amit Langote,
who recognized that getting rid of plancache-related overhead would
be a useful thing to do here. Also thanks to Andres Freund for review.
Discussion: https://postgr.es/m/CAFj8pRDRVfLdAxsWeVLzCAbkLFZhW549K+67tpOc-faC8uH8zw@mail.gmail.com
2020-03-26 23:58:57 +01:00
|
|
|
*
|
|
|
|
* The generation counter is private to namespace.c and shouldn't be touched
|
|
|
|
* by other code. It can be initialized to zero if necessary (that means
|
|
|
|
* "not known equal to the current active path").
|
2007-03-23 20:53:52 +01:00
|
|
|
*/
|
2023-08-01 02:04:47 +02:00
|
|
|
typedef struct SearchPathMatcher
|
2007-03-23 20:53:52 +01:00
|
|
|
{
|
|
|
|
List *schemas; /* OIDs of explicitly named schemas */
|
|
|
|
bool addCatalog; /* implicitly prepend pg_catalog? */
|
|
|
|
bool addTemp; /* implicitly prepend temp schema? */
|
Improve performance of "simple expressions" in PL/pgSQL.
For relatively simple expressions (say, "x + 1" or "x > 0"), plpgsql's
management overhead exceeds the cost of evaluating the expression.
This patch substantially improves that situation, providing roughly
2X speedup for such trivial expressions.
First, add infrastructure in the plancache to allow fast re-validation
of cached plans that contain no table access, and hence need no locks.
Teach plpgsql to use this infrastructure for expressions that it's
already deemed "simple" (which in particular will never contain table
references).
The fast path still requires checking that search_path hasn't changed,
so provide a fast path for OverrideSearchPathMatchesCurrent by
counting changes that have occurred to the active search path in the
current session. This is simplistic but seems enough for now, seeing
that PushOverrideSearchPath is not used in any performance-critical
cases.
Second, manage the refcounts on simple expressions' cached plans using
a transaction-lifespan resource owner, so that we only need to take
and release an expression's refcount once per transaction not once per
expression evaluation. The management of this resource owner exactly
parallels the existing management of plpgsql's simple-expression EState.
Add some regression tests covering this area, in particular verifying
that expression caching doesn't break semantics for search_path changes.
Patch by me, but it owes something to previous work by Amit Langote,
who recognized that getting rid of plancache-related overhead would
be a useful thing to do here. Also thanks to Andres Freund for review.
Discussion: https://postgr.es/m/CAFj8pRDRVfLdAxsWeVLzCAbkLFZhW549K+67tpOc-faC8uH8zw@mail.gmail.com
2020-03-26 23:58:57 +01:00
|
|
|
uint64 generation; /* for quick detection of equality to active */
|
2023-08-01 02:04:47 +02:00
|
|
|
} SearchPathMatcher;
|
2007-03-23 20:53:52 +01:00
|
|
|
|
2018-03-31 01:33:42 +02:00
|
|
|
/*
|
|
|
|
* Option flag bits for RangeVarGetRelidExtended().
|
|
|
|
*/
|
|
|
|
typedef enum RVROption
|
|
|
|
{
|
|
|
|
RVR_MISSING_OK = 1 << 0, /* don't error if relation doesn't exist */
|
2018-03-31 01:56:41 +02:00
|
|
|
RVR_NOWAIT = 1 << 1, /* error if relation cannot be locked */
|
|
|
|
RVR_SKIP_LOCKED = 1 << 2, /* skip if relation cannot be locked */
|
2018-03-31 01:33:42 +02:00
|
|
|
} RVROption;
|
|
|
|
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
typedef void (*RangeVarGetRelidCallback) (const RangeVar *relation, Oid relId,
|
|
|
|
Oid oldRelId, void *callback_arg);
|
2002-04-06 08:59:25 +02:00
|
|
|
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
#define RangeVarGetRelid(relation, lockmode, missing_ok) \
|
2018-03-31 01:33:42 +02:00
|
|
|
RangeVarGetRelidExtended(relation, lockmode, \
|
|
|
|
(missing_ok) ? RVR_MISSING_OK : 0, NULL, NULL)
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
|
|
|
|
extern Oid RangeVarGetRelidExtended(const RangeVar *relation,
|
2018-03-31 01:33:42 +02:00
|
|
|
LOCKMODE lockmode, uint32 flags,
|
Improve table locking behavior in the face of current DDL.
In the previous coding, callers were faced with an awkward choice:
look up the name, do permissions checks, and then lock the table; or
look up the name, lock the table, and then do permissions checks.
The first choice was wrong because the results of the name lookup
and permissions checks might be out-of-date by the time the table
lock was acquired, while the second allowed a user with no privileges
to interfere with access to a table by users who do have privileges
(e.g. if a malicious backend queues up for an AccessExclusiveLock on
a table on which AccessShareLock is already held, further attempts
to access the table will be blocked until the AccessExclusiveLock
is obtained and the malicious backend's transaction rolls back).
To fix, allow callers of RangeVarGetRelid() to pass a callback which
gets executed after performing the name lookup but before acquiring
the relation lock. If the name lookup is retried (because
invalidation messages are received), the callback will be re-executed
as well, so we get the best of both worlds. RangeVarGetRelid() is
renamed to RangeVarGetRelidExtended(); callers not wishing to supply
a callback can continue to invoke it as RangeVarGetRelid(), which is
now a macro. Since the only one caller that uses nowait = true now
passes a callback anyway, the RangeVarGetRelid() macro defaults nowait
as well. The callback can also be used for supplemental locking - for
example, REINDEX INDEX needs to acquire the table lock before the index
lock to reduce deadlock possibilities.
There's a lot more work to be done here to fix all the cases where this
can be a problem, but this commit provides the general infrastructure
and fixes the following specific cases: REINDEX INDEX, REINDEX TABLE,
LOCK TABLE, and and DROP TABLE/INDEX/SEQUENCE/VIEW/FOREIGN TABLE.
Per discussion with Noah Misch and Alvaro Herrera.
2011-11-30 16:12:27 +01:00
|
|
|
RangeVarGetRelidCallback callback,
|
|
|
|
void *callback_arg);
|
2002-03-26 20:17:02 +01:00
|
|
|
extern Oid RangeVarGetCreationNamespace(const RangeVar *newRelation);
|
2022-09-20 04:18:36 +02:00
|
|
|
extern Oid RangeVarGetAndCheckCreationNamespace(RangeVar *relation,
|
Prevent adding relations to a concurrently dropped schema.
In the previous coding, it was possible for a relation to be created
via CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FOREIGN TABLE,
etc. in a schema while that schema was meanwhile being concurrently
dropped. This led to a pg_class entry with an invalid relnamespace
value. The same problem could occur if a relation was moved using
ALTER .. SET SCHEMA while the target schema was being concurrently
dropped. This patch prevents both of those scenarios by locking the
schema to which the relation is being added using AccessShareLock,
which conflicts with the AccessExclusiveLock taken by DROP.
As a desirable side effect, this also prevents the use of CREATE OR
REPLACE VIEW to queue for an AccessExclusiveLock on a relation on which
you have no rights: that will now fail immediately with a permissions
error, before trying to obtain a lock.
We need similar protection for all other object types, but as everything
other than relations uses a slightly different set of code paths, I'm
leaving that for a separate commit.
Original complaint (as far as I could find) about CREATE by Nikhil
Sontakke; risk for ALTER .. SET SCHEMA pointed out by Tom Lane;
further details by Dan Farina; patch by me; review by Hitoshi Harada.
2012-01-16 15:34:21 +01:00
|
|
|
LOCKMODE lockmode,
|
|
|
|
Oid *existing_relation_id);
|
Fix bugs in relpersistence handling during table creation.
Unlike the relistemp field which it replaced, relpersistence must be
set correctly quite early during the table creation process, as we
rely on it quite early on for a number of purposes, including security
checks. Normally, this is set based on whether the user enters CREATE
TABLE, CREATE UNLOGGED TABLE, or CREATE TEMPORARY TABLE, but a
relation may also be made implicitly temporary by creating it in
pg_temp. This patch fixes the handling of that case, and also
disables creation of unlogged tables in temporary tablespace (such
table indeed skip WAL-logging, but we reject an explicit
specification) and creation of relations in the temporary schemas of
other sessions (which is not very sensible, and didn't work right
anyway).
Report by Amit Khandekar.
2011-07-03 23:34:47 +02:00
|
|
|
extern void RangeVarAdjustRelationPersistence(RangeVar *newRelation, Oid nspid);
|
2002-03-26 20:17:02 +01:00
|
|
|
extern Oid RelnameGetRelid(const char *relname);
|
2002-05-02 01:06:41 +02:00
|
|
|
extern bool RelationIsVisible(Oid relid);
|
2002-03-26 20:17:02 +01:00
|
|
|
|
2002-03-30 02:02:42 +01:00
|
|
|
extern Oid TypenameGetTypid(const char *typname);
|
2019-08-05 16:48:41 +02:00
|
|
|
extern Oid TypenameGetTypidExtended(const char *typname, bool temp_ok);
|
2002-05-02 01:06:41 +02:00
|
|
|
extern bool TypeIsVisible(Oid typid);
|
2002-04-17 22:57:57 +02:00
|
|
|
|
2009-10-08 04:39:25 +02:00
|
|
|
extern FuncCandidateList FuncnameGetCandidates(List *names,
|
|
|
|
int nargs, List *argnames,
|
2008-12-18 19:20:35 +01:00
|
|
|
bool expand_variadic,
|
2014-01-23 18:40:29 +01:00
|
|
|
bool expand_defaults,
|
Reconsider the handling of procedure OUT parameters.
Commit 2453ea142 redefined pg_proc.proargtypes to include the types of
OUT parameters, for procedures only. While that had some advantages
for implementing the SQL-spec behavior of DROP PROCEDURE, it was pretty
disastrous from a number of other perspectives. Notably, since the
primary key of pg_proc is name + proargtypes, this made it possible to
have multiple procedures with identical names + input arguments and
differing output argument types. That would make it impossible to call
any one of the procedures by writing just NULL (or "?", or any other
data-type-free notation) for the output argument(s). The change also
seems likely to cause grave confusion for client applications that
examine pg_proc and expect the traditional definition of proargtypes.
Hence, revert the definition of proargtypes to what it was, and
undo a number of complications that had been added to support that.
To support the SQL-spec behavior of DROP PROCEDURE, when there are
no argmode markers in the command's parameter list, we perform the
lookup both ways (that is, matching against both proargtypes and
proallargtypes), succeeding if we get just one unique match.
In principle this could result in ambiguous-function failures
that would not happen when using only one of the two rules.
However, overloading of procedure names is thought to be a pretty
rare usage, so this shouldn't cause many problems in practice.
Postgres-specific code such as pg_dump can defend against any
possibility of such failures by being careful to specify argmodes
for all procedure arguments.
This also fixes a few other bugs in the area of CALL statements
with named parameters, and improves the documentation a little.
catversion bump forced because the representation of procedures
with OUT arguments changes.
Discussion: https://postgr.es/m/3742981.1621533210@sss.pgh.pa.us
2021-06-10 23:11:36 +02:00
|
|
|
bool include_out_arguments,
|
2014-01-23 18:40:29 +01:00
|
|
|
bool missing_ok);
|
2002-05-02 01:06:41 +02:00
|
|
|
extern bool FunctionIsVisible(Oid funcid);
|
2002-04-06 08:59:25 +02:00
|
|
|
|
2006-05-02 01:22:43 +02:00
|
|
|
extern Oid OpernameGetOprid(List *names, Oid oprleft, Oid oprright);
|
2014-04-08 16:27:56 +02:00
|
|
|
extern FuncCandidateList OpernameGetCandidates(List *names, char oprkind,
|
|
|
|
bool missing_schema_ok);
|
2002-05-02 01:06:41 +02:00
|
|
|
extern bool OperatorIsVisible(Oid oprid);
|
2002-04-17 01:08:12 +02:00
|
|
|
|
2002-05-02 01:06:41 +02:00
|
|
|
extern Oid OpclassnameGetOpcid(Oid amid, const char *opcname);
|
|
|
|
extern bool OpclassIsVisible(Oid opcid);
|
2003-01-07 21:56:07 +01:00
|
|
|
|
2006-12-23 01:43:13 +01:00
|
|
|
extern Oid OpfamilynameGetOpfid(Oid amid, const char *opfname);
|
|
|
|
extern bool OpfamilyIsVisible(Oid opfid);
|
|
|
|
|
2011-02-08 22:04:18 +01:00
|
|
|
extern Oid CollationGetCollid(const char *collname);
|
|
|
|
extern bool CollationIsVisible(Oid collid);
|
|
|
|
|
2002-12-12 22:02:25 +01:00
|
|
|
extern Oid ConversionGetConid(const char *conname);
|
2003-01-07 21:56:07 +01:00
|
|
|
extern bool ConversionIsVisible(Oid conid);
|
2002-04-17 22:57:57 +02:00
|
|
|
|
2017-05-14 16:54:47 +02:00
|
|
|
extern Oid get_statistics_object_oid(List *names, bool missing_ok);
|
2023-10-14 22:13:11 +02:00
|
|
|
extern bool StatisticsObjIsVisible(Oid stxid);
|
2017-05-13 06:05:48 +02:00
|
|
|
|
2010-08-05 17:25:36 +02:00
|
|
|
extern Oid get_ts_parser_oid(List *names, bool missing_ok);
|
2007-08-21 03:11:32 +02:00
|
|
|
extern bool TSParserIsVisible(Oid prsId);
|
|
|
|
|
2010-08-05 17:25:36 +02:00
|
|
|
extern Oid get_ts_dict_oid(List *names, bool missing_ok);
|
2007-08-21 03:11:32 +02:00
|
|
|
extern bool TSDictionaryIsVisible(Oid dictId);
|
|
|
|
|
2010-08-05 17:25:36 +02:00
|
|
|
extern Oid get_ts_template_oid(List *names, bool missing_ok);
|
2007-08-21 03:11:32 +02:00
|
|
|
extern bool TSTemplateIsVisible(Oid tmplId);
|
|
|
|
|
2010-08-05 17:25:36 +02:00
|
|
|
extern Oid get_ts_config_oid(List *names, bool missing_ok);
|
2007-08-21 03:11:32 +02:00
|
|
|
extern bool TSConfigIsVisible(Oid cfgid);
|
|
|
|
|
2023-08-23 06:14:11 +02:00
|
|
|
extern void DeconstructQualifiedName(const List *names,
|
2002-07-30 01:46:35 +02:00
|
|
|
char **nspname_p,
|
|
|
|
char **objname_p);
|
2009-10-31 02:41:31 +01:00
|
|
|
extern Oid LookupNamespaceNoError(const char *nspname);
|
2013-01-26 19:24:50 +01:00
|
|
|
extern Oid LookupExplicitNamespace(const char *nspname, bool missing_ok);
|
2010-08-05 16:45:09 +02:00
|
|
|
extern Oid get_namespace_oid(const char *nspname, bool missing_ok);
|
2002-07-30 01:46:35 +02:00
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
extern Oid LookupCreationNamespace(const char *nspname);
|
2015-11-19 16:49:25 +01:00
|
|
|
extern void CheckSetNamespace(Oid oldNspOid, Oid nspOid);
|
2023-08-23 06:14:11 +02:00
|
|
|
extern Oid QualifiedNameGetCreationNamespace(const List *names, char **objname_p);
|
|
|
|
extern RangeVar *makeRangeVarFromNameList(const List *names);
|
|
|
|
extern char *NameListToString(const List *names);
|
|
|
|
extern char *NameListToQuotedString(const List *names);
|
2002-04-09 22:35:55 +02:00
|
|
|
|
2002-03-31 08:26:32 +02:00
|
|
|
extern bool isTempNamespace(Oid namespaceId);
|
2007-07-26 00:16:18 +02:00
|
|
|
extern bool isTempToastNamespace(Oid namespaceId);
|
2014-08-26 03:28:19 +02:00
|
|
|
extern bool isTempOrTempToastNamespace(Oid namespaceId);
|
2005-08-01 06:03:59 +02:00
|
|
|
extern bool isAnyTempNamespace(Oid namespaceId);
|
2002-09-23 22:43:41 +02:00
|
|
|
extern bool isOtherTempNamespace(Oid namespaceId);
|
Avoid failure if autovacuum tries to access a just-dropped temp namespace.
Such an access became possible when commit 246a6c8f7 added more
aggressive cleanup of orphaned temp relations by autovacuum.
Since autovacuum's snapshot might be slightly stale, it could
attempt to access an already-dropped temp namespace, resulting in
an assertion failure or null-pointer dereference. (In practice,
since we don't drop temp namespaces automatically but merely
recycle them, this situation could only arise if a superuser does
a manual drop of a temp namespace. Still, that should be allowed.)
The core of the bug, IMO, is that isTempNamespaceInUse and its callers
failed to think hard about whether to treat "temp namespace isn't there"
differently from "temp namespace isn't in use". In hopes of forestalling
future mistakes of the same ilk, replace that function with a new one
checkTempNamespaceStatus, which makes the same tests but returns a
three-way enum rather than just a bool. isTempNamespaceInUse is gone
entirely in HEAD; but just in case some external code is relying on it,
keep it in the back branches, as a bug-compatible wrapper around the
new function.
Per report originally from Prabhat Kumar Sahu, investigated by Mahendra
Singh and Michael Paquier; the final form of the patch is my fault.
This replaces the failed fix attempt in a052f6cbb.
Backpatch as far as v11, as 246a6c8f7 was.
Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com
2020-02-29 02:28:34 +01:00
|
|
|
extern TempNamespaceStatus checkTempNamespaceStatus(Oid namespaceId);
|
2024-03-03 18:38:22 +01:00
|
|
|
extern ProcNumber GetTempNamespaceProcNumber(Oid namespaceId);
|
2007-07-26 00:16:18 +02:00
|
|
|
extern Oid GetTempToastNamespace(void);
|
Improve the situation for parallel query versus temp relations.
Transmit the leader's temp-namespace state to workers. This is important
because without it, the workers do not really have the same search path
as the leader. For example, there is no good reason (and no extant code
either) to prevent a worker from executing a temp function that the
leader created previously; but as things stood it would fail to find the
temp function, and then either fail or execute the wrong function entirely.
We still prohibit a worker from creating a temp namespace on its own.
In effect, a worker can only see the session's temp namespace if the leader
had created it before starting the worker, which seems like the right
semantics.
Also, transmit the leader's BackendId to workers, and arrange for workers
to use that when determining the physical file path of a temp relation
belonging to their session. While the original intent was to prevent such
accesses entirely, there were a number of holes in that, notably in places
like dbsize.c which assume they can safely access temp rels of other
sessions anyway. We might as well get this right, as a small down payment
on someday allowing workers to access the leader's temp tables. (With
this change, directly using "MyBackendId" as a relation or buffer backend
ID is deprecated; you should use BackendIdForTempRelations() instead.
I left a couple of such uses alone though, as they're not going to be
reachable in parallel workers until we do something about localbuf.c.)
Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down
into localbuf.c, which is where it actually matters, instead of having it
in relation_open(). This amounts to recognizing that access to temp
tables' catalog entries is perfectly safe in a worker, it's only the data
in local buffers that is problematic.
Having done all that, we can get rid of the test in has_parallel_hazard()
that says that use of a temp table's rowtype is unsafe in parallel workers.
That test was unduly expensive, and if we really did need such a
prohibition, that was not even close to being a bulletproof guard for it.
(For example, any user-defined function executed in a parallel worker
might have attempted such access.)
2016-06-10 02:16:11 +02:00
|
|
|
extern void GetTempNamespaceState(Oid *tempNamespaceId,
|
|
|
|
Oid *tempToastNamespaceId);
|
|
|
|
extern void SetTempNamespaceState(Oid tempNamespaceId,
|
|
|
|
Oid tempToastNamespaceId);
|
2007-04-13 00:34:45 +02:00
|
|
|
extern void ResetTempTableNamespace(void);
|
2002-03-31 08:26:32 +02:00
|
|
|
|
2023-08-01 02:04:47 +02:00
|
|
|
extern SearchPathMatcher *GetSearchPathMatcher(MemoryContext context);
|
|
|
|
extern SearchPathMatcher *CopySearchPathMatcher(SearchPathMatcher *path);
|
|
|
|
extern bool SearchPathMatchesCurrentEnvironment(SearchPathMatcher *path);
|
2002-05-17 22:53:33 +02:00
|
|
|
|
2011-02-08 22:04:18 +01:00
|
|
|
extern Oid get_collation_oid(List *collname, bool missing_ok);
|
2010-08-05 17:25:36 +02:00
|
|
|
extern Oid get_conversion_oid(List *conname, bool missing_ok);
|
2012-06-25 00:51:46 +02:00
|
|
|
extern Oid FindDefaultConversionProc(int32 for_encoding, int32 to_encoding);
|
2002-07-16 08:58:14 +02:00
|
|
|
|
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
|
|
|
|
2002-05-17 22:53:33 +02:00
|
|
|
/* initialization & transaction cleanup code */
|
|
|
|
extern void InitializeSearchPath(void);
|
Create an infrastructure for parallel computation in PostgreSQL.
This does four basic things. First, it provides convenience routines
to coordinate the startup and shutdown of parallel workers. Second,
it synchronizes various pieces of state (e.g. GUCs, combo CID
mappings, transaction snapshot) from the parallel group leader to the
worker processes. Third, it prohibits various operations that would
result in unsafe changes to that state while parallelism is active.
Finally, it propagates events that would result in an ErrorResponse,
NoticeResponse, or NotifyResponse message being sent to the client
from the parallel workers back to the master, from which they can then
be sent on to the client.
Robert Haas, Amit Kapila, Noah Misch, Rushabh Lathia, Jeevan Chalke.
Suggestions and review from Andres Freund, Heikki Linnakangas, Noah
Misch, Simon Riggs, Euler Taveira, and Jim Nasby.
2015-04-30 21:02:14 +02:00
|
|
|
extern void AtEOXact_Namespace(bool isCommit, bool parallel);
|
2004-09-16 18:58:44 +02:00
|
|
|
extern void AtEOSubXact_Namespace(bool isCommit, SubTransactionId mySubid,
|
|
|
|
SubTransactionId parentSubid);
|
2002-05-17 22:53:33 +02:00
|
|
|
|
2002-04-01 05:34:27 +02:00
|
|
|
/* stuff for search_path GUC variable */
|
2022-04-08 14:16:38 +02:00
|
|
|
extern PGDLLIMPORT char *namespace_search_path;
|
2002-04-01 05:34:27 +02:00
|
|
|
|
2002-05-17 22:53:33 +02:00
|
|
|
extern List *fetch_search_path(bool includeImplicit);
|
2007-11-28 19:47:56 +01:00
|
|
|
extern int fetch_search_path_array(Oid *sarray, int sarray_len);
|
2002-04-26 03:24:08 +02:00
|
|
|
|
2002-03-26 20:17:02 +01:00
|
|
|
#endif /* NAMESPACE_H */
|