2002-03-26 20:17:02 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* namespace.h
|
|
|
|
* prototypes for functions in backend/catalog/namespace.c
|
|
|
|
*
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, 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"
|
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
|
2014-05-06 18:12:18 +02:00
|
|
|
* found by namespace lookup. Each function/operator is identified
|
2002-04-06 08:59:25 +02:00
|
|
|
* 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 */
|
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 */
|
2017-06-21 20:39:04 +02:00
|
|
|
} *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
|
|
|
/*
|
|
|
|
* Structure for xxxOverrideSearchPath functions
|
|
|
|
*/
|
|
|
|
typedef struct OverrideSearchPath
|
|
|
|
{
|
|
|
|
List *schemas; /* OIDs of explicitly named schemas */
|
|
|
|
bool addCatalog; /* implicitly prepend pg_catalog? */
|
|
|
|
bool addTemp; /* implicitly prepend temp schema? */
|
2007-11-15 23:25:18 +01:00
|
|
|
} OverrideSearchPath;
|
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;
|
|
|
|
|
2012-06-10 21:20:04 +02:00
|
|
|
typedef void (*RangeVarGetRelidCallback) (const RangeVar *relation, Oid relId,
|
2017-06-21 20:39:04 +02:00
|
|
|
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
|
|
|
|
2019-05-22 19:04:48 +02:00
|
|
|
extern Oid RangeVarGetRelidExtended(const RangeVar *relation,
|
|
|
|
LOCKMODE lockmode, uint32 flags,
|
|
|
|
RangeVarGetRelidCallback callback,
|
|
|
|
void *callback_arg);
|
2002-03-26 20:17:02 +01:00
|
|
|
extern Oid RangeVarGetCreationNamespace(const RangeVar *newRelation);
|
2019-05-22 19:04:48 +02:00
|
|
|
extern Oid RangeVarGetAndCheckCreationNamespace(RangeVar *newRelation,
|
|
|
|
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,
|
2019-05-22 19:04:48 +02:00
|
|
|
int nargs, List *argnames,
|
|
|
|
bool expand_variadic,
|
|
|
|
bool expand_defaults,
|
|
|
|
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,
|
2019-05-22 19:04:48 +02:00
|
|
|
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);
|
2019-08-13 06:53:41 +02:00
|
|
|
extern bool StatisticsObjIsVisible(Oid relid);
|
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);
|
|
|
|
|
2002-07-30 01:46:35 +02:00
|
|
|
extern void DeconstructQualifiedName(List *names,
|
2019-05-22 19:04:48 +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);
|
2002-03-29 20:06:29 +01:00
|
|
|
extern Oid QualifiedNameGetCreationNamespace(List *names, char **objname_p);
|
|
|
|
extern RangeVar *makeRangeVarFromNameList(List *names);
|
2002-04-09 22:35:55 +02:00
|
|
|
extern char *NameListToString(List *names);
|
2002-11-02 19:41:22 +01:00
|
|
|
extern char *NameListToQuotedString(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);
|
2008-07-01 04:09:34 +02:00
|
|
|
extern int GetTempNamespaceBackendId(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,
|
2019-05-22 19:04:48 +02:00
|
|
|
Oid *tempToastNamespaceId);
|
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 SetTempNamespaceState(Oid tempNamespaceId,
|
2019-05-22 19:04:48 +02:00
|
|
|
Oid tempToastNamespaceId);
|
2007-04-13 00:34:45 +02:00
|
|
|
extern void ResetTempTableNamespace(void);
|
2002-03-31 08:26:32 +02:00
|
|
|
|
2007-03-23 20:53:52 +01:00
|
|
|
extern OverrideSearchPath *GetOverrideSearchPath(MemoryContext context);
|
2011-09-16 06:42:53 +02:00
|
|
|
extern OverrideSearchPath *CopyOverrideSearchPath(OverrideSearchPath *path);
|
Change plan caching to honor, not resist, changes in search_path.
In the initial implementation of plan caching, we saved the active
search_path when a plan was first cached, then reinstalled that path
anytime we needed to reparse or replan. The idea of that was to try to
reselect the same referenced objects, in somewhat the same way that views
continue to refer to the same objects in the face of schema or name
changes. Of course, that analogy doesn't bear close inspection, since
holding the search_path fixed doesn't cope with object drops or renames.
Moreover sticking with the old path seems to create more surprises than
it avoids. So instead of doing that, consider that the cached plan depends
on search_path, and force reparse/replan if the active search_path is
different than it was when we last saved the plan.
This gets us fairly close to having "transparency" of plan caching, in the
sense that the cached statement acts the same as if you'd just resubmitted
the original query text for another execution. There are still some corner
cases where this fails though: a new object added in the search path
schema(s) might capture a reference in the query text, but we'd not realize
that and force a reparse. We might try to fix that in the future, but for
the moment it looks too expensive and complicated.
2013-01-25 20:14:41 +01:00
|
|
|
extern bool OverrideSearchPathMatchesCurrent(OverrideSearchPath *path);
|
2007-11-15 23:25:18 +01:00
|
|
|
extern void PushOverrideSearchPath(OverrideSearchPath *newpath);
|
2007-03-23 20:53:52 +01:00
|
|
|
extern void PopOverrideSearchPath(void);
|
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,
|
2019-05-22 19:04:48 +02:00
|
|
|
SubTransactionId parentSubid);
|
2002-05-17 22:53:33 +02:00
|
|
|
|
2002-04-01 05:34:27 +02:00
|
|
|
/* stuff for search_path GUC variable */
|
|
|
|
extern char *namespace_search_path;
|
|
|
|
|
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
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* NAMESPACE_H */
|