1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* view.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* use rewrite rules to construct views
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2012-01-02 00:01:58 +01:00
|
|
|
* Portions Copyright (c) 1996-2012, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-09-02 04:13:02 +02:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/commands/view.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "postgres.h"
|
1996-11-06 09:21:43 +01:00
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
#include "access/heapam.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/xact.h"
|
2002-03-29 20:06:29 +01:00
|
|
|
#include "catalog/namespace.h"
|
2006-07-02 04:23:23 +02:00
|
|
|
#include "commands/defrem.h"
|
2002-04-15 07:22:04 +02:00
|
|
|
#include "commands/tablecmds.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "commands/view.h"
|
2000-07-04 08:11:54 +02:00
|
|
|
#include "miscadmin.h"
|
2000-02-15 04:38:29 +01:00
|
|
|
#include "nodes/makefuncs.h"
|
2008-08-26 00:42:34 +02:00
|
|
|
#include "nodes/nodeFuncs.h"
|
2007-03-13 01:33:44 +01:00
|
|
|
#include "parser/analyze.h"
|
1999-07-16 01:04:24 +02:00
|
|
|
#include "parser/parse_relation.h"
|
|
|
|
#include "rewrite/rewriteDefine.h"
|
|
|
|
#include "rewrite/rewriteManip.h"
|
2001-08-12 23:35:19 +02:00
|
|
|
#include "rewrite/rewriteSupport.h"
|
2002-09-02 04:13:02 +02:00
|
|
|
#include "utils/acl.h"
|
2008-12-16 01:56:12 +01:00
|
|
|
#include "utils/builtins.h"
|
2002-09-02 04:13:02 +02:00
|
|
|
#include "utils/lsyscache.h"
|
2008-06-19 02:46:06 +02:00
|
|
|
#include "utils/rel.h"
|
2011-12-22 22:15:57 +01:00
|
|
|
#include "utils/syscache.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-10-26 19:04:12 +02:00
|
|
|
|
2002-09-02 22:04:40 +02:00
|
|
|
static void checkViewTupleDesc(TupleDesc newdesc, TupleDesc olddesc);
|
2005-02-02 07:36:02 +01:00
|
|
|
static bool isViewOnTempTable_walker(Node *node, void *context);
|
2002-09-02 22:04:40 +02:00
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* isViewOnTempTable
|
|
|
|
*
|
|
|
|
* Returns true iff any of the relations underlying this view are
|
|
|
|
* temporary tables.
|
|
|
|
*---------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
isViewOnTempTable(Query *viewParse)
|
|
|
|
{
|
|
|
|
return isViewOnTempTable_walker((Node *) viewParse, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
isViewOnTempTable_walker(Node *node, void *context)
|
|
|
|
{
|
|
|
|
if (node == NULL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (IsA(node, Query))
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
Query *query = (Query *) node;
|
|
|
|
ListCell *rtable;
|
2005-02-02 07:36:02 +01:00
|
|
|
|
2005-10-15 04:49:52 +02:00
|
|
|
foreach(rtable, query->rtable)
|
2005-02-02 07:36:02 +01:00
|
|
|
{
|
|
|
|
RangeTblEntry *rte = lfirst(rtable);
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
if (rte->rtekind == RTE_RELATION)
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
Relation rel = heap_open(rte->relid, AccessShareLock);
|
2010-12-13 18:34:26 +01:00
|
|
|
char relpersistence = rel->rd_rel->relpersistence;
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
heap_close(rel, AccessShareLock);
|
2010-12-13 18:34:26 +01:00
|
|
|
if (relpersistence == RELPERSISTENCE_TEMP)
|
2005-02-02 07:36:02 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return query_tree_walker(query,
|
|
|
|
isViewOnTempTable_walker,
|
|
|
|
context,
|
|
|
|
QTW_IGNORE_JOINALIASES);
|
|
|
|
}
|
|
|
|
|
|
|
|
return expression_tree_walker(node,
|
|
|
|
isViewOnTempTable_walker,
|
|
|
|
context);
|
|
|
|
}
|
2002-09-02 22:04:40 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* DefineVirtualRelation
|
|
|
|
*
|
2002-09-02 04:13:02 +02:00
|
|
|
* Create the "view" relation. `DefineRelation' does all the work,
|
|
|
|
* we just provide the correct arguments ... at least when we're
|
|
|
|
* creating a view. If we're updating an existing view, we have to
|
|
|
|
* work harder.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------------------
|
|
|
|
*/
|
2002-03-22 03:56:37 +01:00
|
|
|
static Oid
|
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
|
|
|
DefineVirtualRelation(RangeVar *relation, List *tlist, bool replace,
|
|
|
|
List *options)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
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
|
|
|
Oid viewOid;
|
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;
|
2000-09-29 20:21:41 +02:00
|
|
|
CreateStmt *createStmt = makeNode(CreateStmt);
|
2004-05-26 06:41:50 +02:00
|
|
|
List *attrList;
|
|
|
|
ListCell *t;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* create a list of ColumnDef nodes based on the names and types of the
|
|
|
|
* (non-junk) targetlist items from the view's SELECT list.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
attrList = NIL;
|
2002-09-04 22:31:48 +02:00
|
|
|
foreach(t, tlist)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2005-04-06 18:34:07 +02:00
|
|
|
TargetEntry *tle = lfirst(t);
|
2000-09-29 20:21:41 +02:00
|
|
|
|
2005-04-06 18:34:07 +02:00
|
|
|
if (!tle->resjunk)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
ColumnDef *def = makeNode(ColumnDef);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-04-06 18:34:07 +02:00
|
|
|
def->colname = pstrdup(tle->resname);
|
2009-07-16 08:33:46 +02:00
|
|
|
def->typeName = makeTypeNameFromOid(exprType((Node *) tle->expr),
|
2011-04-10 17:42:00 +02:00
|
|
|
exprTypmod((Node *) tle->expr));
|
2002-09-22 21:42:52 +02:00
|
|
|
def->inhcount = 0;
|
|
|
|
def->is_local = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
def->is_not_null = false;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
def->is_from_type = false;
|
2009-10-13 02:53:08 +02:00
|
|
|
def->storage = 0;
|
1999-10-04 01:55:40 +02:00
|
|
|
def->raw_default = NULL;
|
|
|
|
def->cooked_default = NULL;
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
def->collClause = NULL;
|
2011-03-20 01:29:08 +01:00
|
|
|
def->collOid = exprCollation((Node *) tle->expr);
|
2011-04-10 17:42:00 +02:00
|
|
|
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
/*
|
2011-03-20 01:29:08 +01:00
|
|
|
* It's possible that the column is of a collatable type but the
|
|
|
|
* collation could not be resolved, so double-check.
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
*/
|
|
|
|
if (type_is_collatable(exprType((Node *) tle->expr)))
|
2011-03-20 01:29:08 +01:00
|
|
|
{
|
|
|
|
if (!OidIsValid(def->collOid))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INDETERMINATE_COLLATION),
|
2011-03-22 21:55:32 +01:00
|
|
|
errmsg("could not determine which collation to use for view column \"%s\"",
|
2011-03-20 01:29:08 +01:00
|
|
|
def->colname),
|
|
|
|
errhint("Use the COLLATE clause to set the collation explicitly.")));
|
|
|
|
}
|
Remove collation information from TypeName, where it does not belong.
The initial collations patch treated a COLLATE spec as part of a TypeName,
following what can only be described as brain fade on the part of the SQL
committee. It's a lot more reasonable to treat COLLATE as a syntactically
separate object, so that it can be added in only the productions where it
actually belongs, rather than needing to reject it in a boatload of places
where it doesn't belong (something the original patch mostly failed to do).
In addition this change lets us meet the spec's requirement to allow
COLLATE anywhere in the clauses of a ColumnDef, and it avoids unfriendly
behavior for constructs such as "foo::type COLLATE collation".
To do this, pull collation information out of TypeName and put it in
ColumnDef instead, thus reverting most of the collation-related changes in
parse_type.c's API. I made one additional structural change, which was to
use a ColumnDef as an intermediate node in AT_AlterColumnType AlterTableCmd
nodes. This provides enough room to get rid of the "transform" wart in
AlterTableCmd too, since the ColumnDef can carry the USING expression
easily enough.
Also fix some other minor bugs that have crept in in the same areas,
like failure to copy recently-added fields of ColumnDef in copyfuncs.c.
While at it, document the formerly secret ability to specify a collation
in ALTER TABLE ALTER COLUMN TYPE, ALTER TYPE ADD ATTRIBUTE, and
ALTER TYPE ALTER ATTRIBUTE TYPE; and correct some misstatements about
what the default collation selection will be when COLLATE is omitted.
BTW, the three-parameter form of format_type() should go away too,
since it just contributes to the confusion in this area; but I'll do
that in a separate patch.
2011-03-10 04:38:52 +01:00
|
|
|
else
|
2011-03-20 01:29:08 +01:00
|
|
|
Assert(!OidIsValid(def->collOid));
|
2000-09-29 20:21:41 +02:00
|
|
|
def->constraints = NIL;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
attrList = lappend(attrList, def);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2000-09-29 20:21:41 +02:00
|
|
|
|
|
|
|
if (attrList == NIL)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("view must have at least one column")));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
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
|
|
|
* Look up, check permissions on, and lock the creation namespace; also
|
|
|
|
* check for a preexisting view with the same name. This will also set
|
|
|
|
* relation->relpersistence to RELPERSISTENCE_TEMP if the selected
|
|
|
|
* namespace is temporary.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
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 = replace ? AccessExclusiveLock : NoLock;
|
2012-01-18 10:22:54 +01:00
|
|
|
(void) RangeVarGetAndCheckCreationNamespace(relation, lockmode, &viewOid);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
if (OidIsValid(viewOid) && replace)
|
|
|
|
{
|
|
|
|
Relation rel;
|
|
|
|
TupleDesc descriptor;
|
2011-12-22 22:15:57 +01:00
|
|
|
List *atcmds = NIL;
|
|
|
|
AlterTableCmd *atcmd;
|
2002-09-02 04:13:02 +02:00
|
|
|
|
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
|
|
|
/* Relation is already locked, but we must build a relcache entry. */
|
|
|
|
rel = relation_open(viewOid, NoLock);
|
2002-09-02 04:13:02 +02:00
|
|
|
|
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
|
|
|
/* Make sure it *is* a view. */
|
2002-09-02 04:13:02 +02:00
|
|
|
if (rel->rd_rel->relkind != RELKIND_VIEW)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
|
|
|
|
errmsg("\"%s\" is not a view",
|
|
|
|
RelationGetRelationName(rel))));
|
2002-09-02 04:13:02 +02:00
|
|
|
|
2008-12-15 22:35:31 +01:00
|
|
|
/* Also check it's not in use already */
|
|
|
|
CheckTableNotInUse(rel, "CREATE OR REPLACE VIEW");
|
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Due to the namespace visibility rules for temporary objects, we
|
|
|
|
* should only end up replacing a temporary view with another
|
2010-12-13 18:34:26 +01:00
|
|
|
* temporary view, and similarly for permanent views.
|
2005-02-02 07:36:02 +01:00
|
|
|
*/
|
2010-12-13 18:34:26 +01:00
|
|
|
Assert(relation->relpersistence == rel->rd_rel->relpersistence);
|
2005-02-02 07:36:02 +01:00
|
|
|
|
2008-12-07 00:22:46 +01:00
|
|
|
/*
|
2008-12-15 22:35:31 +01:00
|
|
|
* Create a tuple descriptor to compare against the existing view, and
|
|
|
|
* verify that the old column list is an initial prefix of the new
|
|
|
|
* column list.
|
|
|
|
*/
|
|
|
|
descriptor = BuildDescForRelation(attrList);
|
|
|
|
checkViewTupleDesc(descriptor, rel->rd_att);
|
|
|
|
|
2011-12-22 22:15:57 +01:00
|
|
|
/*
|
|
|
|
* The new options list replaces the existing options list, even
|
|
|
|
* if it's empty.
|
|
|
|
*/
|
|
|
|
atcmd = makeNode(AlterTableCmd);
|
|
|
|
atcmd->subtype = AT_ReplaceRelOptions;
|
|
|
|
atcmd->def = (Node *) options;
|
|
|
|
atcmds = lappend(atcmds, atcmd);
|
|
|
|
|
2008-12-15 22:35:31 +01:00
|
|
|
/*
|
2009-06-11 16:49:15 +02:00
|
|
|
* If new attributes have been added, we must add pg_attribute entries
|
2008-12-15 22:35:31 +01:00
|
|
|
* for them. It is convenient (although overkill) to use the ALTER
|
|
|
|
* TABLE ADD COLUMN infrastructure for this.
|
|
|
|
*/
|
|
|
|
if (list_length(attrList) > rel->rd_att->natts)
|
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
ListCell *c;
|
2008-12-07 00:22:46 +01:00
|
|
|
int skip = rel->rd_att->natts;
|
|
|
|
|
2008-12-15 22:35:31 +01:00
|
|
|
foreach(c, attrList)
|
|
|
|
{
|
|
|
|
if (skip > 0)
|
|
|
|
{
|
|
|
|
skip--;
|
2008-12-07 00:22:46 +01:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
atcmd = makeNode(AlterTableCmd);
|
|
|
|
atcmd->subtype = AT_AddColumnToView;
|
2008-12-15 22:35:31 +01:00
|
|
|
atcmd->def = (Node *) lfirst(c);
|
2008-12-07 00:22:46 +01:00
|
|
|
atcmds = lappend(atcmds, atcmd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-22 22:15:57 +01:00
|
|
|
/* OK, let's do it. */
|
|
|
|
AlterTableInternal(viewOid, atcmds, true);
|
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
/*
|
|
|
|
* Seems okay, so return the OID of the pre-existing view.
|
|
|
|
*/
|
2002-09-04 22:31:48 +02:00
|
|
|
relation_close(rel, NoLock); /* keep the lock! */
|
2002-09-02 04:13:02 +02:00
|
|
|
|
|
|
|
return viewOid;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
Oid relid;
|
2010-07-26 01:21:22 +02:00
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* now set the parameters for keys/inheritance etc. All of these are
|
|
|
|
* uninteresting for views...
|
2002-09-02 04:13:02 +02:00
|
|
|
*/
|
2012-02-26 14:22:27 +01:00
|
|
|
createStmt->relation = relation;
|
2002-09-02 04:13:02 +02:00
|
|
|
createStmt->tableElts = attrList;
|
|
|
|
createStmt->inhRelations = NIL;
|
|
|
|
createStmt->constraints = NIL;
|
2011-12-22 22:15:57 +01:00
|
|
|
createStmt->options = options;
|
|
|
|
createStmt->options = lappend(options, defWithOids(false));
|
2002-11-11 23:19:25 +01:00
|
|
|
createStmt->oncommit = ONCOMMIT_NOOP;
|
2004-06-18 08:14:31 +02:00
|
|
|
createStmt->tablespacename = NULL;
|
2010-07-26 01:21:22 +02:00
|
|
|
createStmt->if_not_exists = false;
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2002-09-02 04:13:02 +02:00
|
|
|
/*
|
2002-09-04 22:31:48 +02:00
|
|
|
* finally create the relation (this will error out if there's an
|
2005-10-15 04:49:52 +02:00
|
|
|
* existing view, so we don't need more code to complain if "replace"
|
|
|
|
* is false).
|
2002-09-02 04:13:02 +02:00
|
|
|
*/
|
2010-08-18 20:35:21 +02:00
|
|
|
relid = DefineRelation(createStmt, RELKIND_VIEW, InvalidOid);
|
2010-07-26 01:21:22 +02:00
|
|
|
Assert(relid != InvalidOid);
|
|
|
|
return relid;
|
2002-09-02 04:13:02 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-09-02 22:04:40 +02:00
|
|
|
/*
|
|
|
|
* Verify that tupledesc associated with proposed new view definition
|
|
|
|
* matches tupledesc of old view. This is basically a cut-down version
|
|
|
|
* of equalTupleDescs(), with code added to generate specific complaints.
|
2008-12-15 22:35:31 +01:00
|
|
|
* Also, we allow the new tupledesc to have more columns than the old.
|
2002-09-02 22:04:40 +02:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
checkViewTupleDesc(TupleDesc newdesc, TupleDesc olddesc)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2008-12-07 00:22:46 +01:00
|
|
|
if (newdesc->natts < olddesc->natts)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
2008-12-07 00:22:46 +01:00
|
|
|
errmsg("cannot drop columns from view")));
|
2002-09-02 22:04:40 +02:00
|
|
|
/* we can ignore tdhasoid */
|
|
|
|
|
2008-12-07 00:22:46 +01:00
|
|
|
for (i = 0; i < olddesc->natts; i++)
|
2002-09-02 22:04:40 +02:00
|
|
|
{
|
|
|
|
Form_pg_attribute newattr = newdesc->attrs[i];
|
|
|
|
Form_pg_attribute oldattr = olddesc->attrs[i];
|
|
|
|
|
2008-12-16 01:56:12 +01:00
|
|
|
/* XXX msg not right, but we don't support DROP COL on view anyway */
|
2002-09-02 22:04:40 +02:00
|
|
|
if (newattr->attisdropped != oldattr->attisdropped)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
2008-12-07 00:22:46 +01:00
|
|
|
errmsg("cannot drop columns from view")));
|
2002-09-02 22:04:40 +02:00
|
|
|
|
|
|
|
if (strcmp(NameStr(newattr->attname), NameStr(oldattr->attname)) != 0)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
2009-06-11 16:49:15 +02:00
|
|
|
errmsg("cannot change name of view column \"%s\" to \"%s\"",
|
|
|
|
NameStr(oldattr->attname),
|
|
|
|
NameStr(newattr->attname))));
|
2002-09-02 22:04:40 +02:00
|
|
|
/* XXX would it be safe to allow atttypmod to change? Not sure */
|
|
|
|
if (newattr->atttypid != oldattr->atttypid ||
|
|
|
|
newattr->atttypmod != oldattr->atttypmod)
|
2003-07-20 23:56:35 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
|
2008-12-16 01:56:12 +01:00
|
|
|
errmsg("cannot change data type of view column \"%s\" from %s to %s",
|
|
|
|
NameStr(oldattr->attname),
|
|
|
|
format_type_with_typemod(oldattr->atttypid,
|
|
|
|
oldattr->atttypmod),
|
|
|
|
format_type_with_typemod(newattr->atttypid,
|
|
|
|
newattr->atttypmod))));
|
2002-09-02 22:04:40 +02:00
|
|
|
/* We can ignore the remaining attributes of an attribute... */
|
|
|
|
}
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2002-09-02 22:04:40 +02:00
|
|
|
/*
|
|
|
|
* We ignore the constraint fields. The new view desc can't have any
|
|
|
|
* constraints, and the only ones that could be on the old view are
|
|
|
|
* defaults, which we are happy to leave in place.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
static void
|
2007-08-27 05:36:08 +02:00
|
|
|
DefineViewRules(Oid viewOid, Query *viewParse, bool replace)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2007-03-13 01:33:44 +01:00
|
|
|
/*
|
|
|
|
* Set up the ON SELECT rule. Since the query has already been through
|
|
|
|
* parse analysis, we use DefineQueryRewrite() directly.
|
|
|
|
*/
|
|
|
|
DefineQueryRewrite(pstrdup(ViewSelectRuleName),
|
2007-08-27 05:36:08 +02:00
|
|
|
viewOid,
|
2007-03-13 01:33:44 +01:00
|
|
|
NULL,
|
|
|
|
CMD_SELECT,
|
2009-01-27 13:40:15 +01:00
|
|
|
true,
|
2007-03-13 01:33:44 +01:00
|
|
|
replace,
|
|
|
|
list_make1(viewParse));
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
/*
|
2009-01-27 13:40:15 +01:00
|
|
|
* Someday: automatic ON INSERT, etc
|
2007-03-13 01:33:44 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------
|
|
|
|
* UpdateRangeTableOfViewParse
|
|
|
|
*
|
|
|
|
* Update the range table of the given parsetree.
|
|
|
|
* This update consists of adding two new entries IN THE BEGINNING
|
|
|
|
* of the range table (otherwise the rule system will die a slow,
|
|
|
|
* horrible and painful death, and we do not want that now, do we?)
|
2000-06-12 21:40:58 +02:00
|
|
|
* one for the OLD relation and one for the NEW one (both of
|
1996-07-09 08:22:35 +02:00
|
|
|
* them refer in fact to the "view" relation).
|
|
|
|
*
|
|
|
|
* Of course we must also increase the 'varnos' of all the Var nodes
|
|
|
|
* by 2...
|
|
|
|
*
|
2000-12-21 18:36:15 +01:00
|
|
|
* These extra RT entries are not actually used in the query,
|
|
|
|
* except for run-time permission checking.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------------
|
|
|
|
*/
|
2000-12-21 18:36:15 +01:00
|
|
|
static Query *
|
2002-03-22 03:56:37 +01:00
|
|
|
UpdateRangeTableOfViewParse(Oid viewOid, Query *viewParse)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2005-04-13 18:50:55 +02:00
|
|
|
Relation viewRel;
|
1997-09-08 04:41:22 +02:00
|
|
|
List *new_rt;
|
|
|
|
RangeTblEntry *rt_entry1,
|
|
|
|
*rt_entry2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2001-03-22 05:01:46 +01:00
|
|
|
* Make a copy of the given parsetree. It's not so much that we don't
|
2005-10-15 04:49:52 +02:00
|
|
|
* want to scribble on our input, it's that the parser has a bad habit of
|
|
|
|
* outputting multiple links to the same subtree for constructs like
|
|
|
|
* BETWEEN, and we mustn't have OffsetVarNodes increment the varno of a
|
|
|
|
* Var node twice. copyObject will expand any multiply-referenced subtree
|
|
|
|
* into multiple copies.
|
2000-12-21 18:36:15 +01:00
|
|
|
*/
|
|
|
|
viewParse = (Query *) copyObject(viewParse);
|
|
|
|
|
2005-04-13 18:50:55 +02:00
|
|
|
/* need to open the rel for addRangeTableEntryForRelation */
|
|
|
|
viewRel = relation_open(viewOid, AccessShareLock);
|
|
|
|
|
2000-12-21 18:36:15 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Create the 2 new range table entries and form the new range table...
|
|
|
|
* OLD first, then NEW....
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2005-04-13 18:50:55 +02:00
|
|
|
rt_entry1 = addRangeTableEntryForRelation(NULL, viewRel,
|
2009-11-06 00:24:27 +01:00
|
|
|
makeAlias("old", NIL),
|
2002-03-22 03:56:37 +01:00
|
|
|
false, false);
|
2005-04-13 18:50:55 +02:00
|
|
|
rt_entry2 = addRangeTableEntryForRelation(NULL, viewRel,
|
2009-11-06 00:24:27 +01:00
|
|
|
makeAlias("new", NIL),
|
2002-03-22 03:56:37 +01:00
|
|
|
false, false);
|
2000-09-29 20:21:41 +02:00
|
|
|
/* Must override addRangeTableEntry's default access-check flags */
|
2004-01-15 00:01:55 +01:00
|
|
|
rt_entry1->requiredPerms = 0;
|
|
|
|
rt_entry2->requiredPerms = 0;
|
2000-09-29 20:21:41 +02:00
|
|
|
|
2000-09-12 23:07:18 +02:00
|
|
|
new_rt = lcons(rt_entry1, lcons(rt_entry2, viewParse->rtable));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
viewParse->rtable = new_rt;
|
2000-09-12 23:07:18 +02:00
|
|
|
|
|
|
|
/*
|
2000-12-21 18:36:15 +01:00
|
|
|
* Now offset all var nodes by 2, and jointree RT indexes too.
|
2000-09-12 23:07:18 +02:00
|
|
|
*/
|
|
|
|
OffsetVarNodes((Node *) viewParse, 2, 0);
|
2000-12-21 18:36:15 +01:00
|
|
|
|
2005-04-13 18:50:55 +02:00
|
|
|
relation_close(viewRel, AccessShareLock);
|
|
|
|
|
2000-12-21 18:36:15 +01:00
|
|
|
return viewParse;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
/*
|
1996-07-09 08:22:35 +02:00
|
|
|
* DefineView
|
2007-03-13 01:33:44 +01:00
|
|
|
* Execute a CREATE VIEW command.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
void
|
2007-03-13 01:33:44 +01:00
|
|
|
DefineView(ViewStmt *stmt, const char *queryString)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2007-03-13 01:33:44 +01:00
|
|
|
Query *viewParse;
|
2002-03-22 03:56:37 +01:00
|
|
|
Oid viewOid;
|
2007-03-13 01:33:44 +01:00
|
|
|
RangeVar *view;
|
|
|
|
|
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* Run parse analysis to convert the raw parse tree to a Query. Note this
|
|
|
|
* also acquires sufficient locks on the source table(s).
|
2007-03-13 01:33:44 +01:00
|
|
|
*
|
|
|
|
* Since parse analysis scribbles on its input, copy the raw parse tree;
|
|
|
|
* this ensures we don't corrupt a prepared statement, for example.
|
|
|
|
*/
|
2007-06-24 00:12:52 +02:00
|
|
|
viewParse = parse_analyze((Node *) copyObject(stmt->query),
|
|
|
|
queryString, NULL, 0);
|
2007-03-13 01:33:44 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The grammar should ensure that the result is a single SELECT Query.
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
* However, it doesn't forbid SELECT INTO, so we have to check for that.
|
2007-03-13 01:33:44 +01:00
|
|
|
*/
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
if (!IsA(viewParse, Query))
|
|
|
|
elog(ERROR, "unexpected parse analysis result");
|
|
|
|
if (viewParse->utilityStmt != NULL &&
|
|
|
|
IsA(viewParse->utilityStmt, CreateTableAsStmt))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("views must not contain SELECT INTO")));
|
|
|
|
if (viewParse->commandType != CMD_SELECT ||
|
|
|
|
viewParse->utilityStmt != NULL)
|
2007-03-13 01:33:44 +01:00
|
|
|
elog(ERROR, "unexpected parse analysis result");
|
|
|
|
|
2011-02-26 00:56:23 +01:00
|
|
|
/*
|
|
|
|
* Check for unsupported cases. These tests are redundant with ones in
|
2011-04-10 17:42:00 +02:00
|
|
|
* DefineQueryRewrite(), but that function will complain about a bogus ON
|
|
|
|
* SELECT rule, and we'd rather the message complain about a view.
|
2011-02-26 00:56:23 +01:00
|
|
|
*/
|
|
|
|
if (viewParse->hasModifyingCTE)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2011-04-10 17:42:00 +02:00
|
|
|
errmsg("views must not contain data-modifying statements in WITH")));
|
2011-02-26 00:56:23 +01:00
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
/*
|
|
|
|
* If a list of column names was given, run through and insert these into
|
|
|
|
* the actual query tree. - thomas 2000-03-08
|
|
|
|
*/
|
|
|
|
if (stmt->aliases != NIL)
|
|
|
|
{
|
|
|
|
ListCell *alist_item = list_head(stmt->aliases);
|
|
|
|
ListCell *targetList;
|
|
|
|
|
|
|
|
foreach(targetList, viewParse->targetList)
|
|
|
|
{
|
|
|
|
TargetEntry *te = (TargetEntry *) lfirst(targetList);
|
|
|
|
|
|
|
|
Assert(IsA(te, TargetEntry));
|
|
|
|
/* junk columns don't get aliases */
|
|
|
|
if (te->resjunk)
|
|
|
|
continue;
|
|
|
|
te->resname = pstrdup(strVal(lfirst(alist_item)));
|
|
|
|
alist_item = lnext(alist_item);
|
|
|
|
if (alist_item == NULL)
|
|
|
|
break; /* done assigning aliases */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (alist_item != NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("CREATE VIEW specifies more column "
|
|
|
|
"names than columns")));
|
|
|
|
}
|
2002-03-22 03:56:37 +01:00
|
|
|
|
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
|
|
|
/* Unlogged views are not sensible. */
|
|
|
|
if (stmt->view->relpersistence == RELPERSISTENCE_UNLOGGED)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("views cannot be unlogged because they do not have storage")));
|
|
|
|
|
2005-02-02 07:36:02 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* If the user didn't explicitly ask for a temporary view, check whether
|
2007-11-15 22:14:46 +01:00
|
|
|
* we need one implicitly. We allow TEMP to be inserted automatically as
|
|
|
|
* long as the CREATE command is consistent with that --- no explicit
|
2007-08-27 05:36:08 +02:00
|
|
|
* schema name.
|
2005-02-02 07:36:02 +01:00
|
|
|
*/
|
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
|
|
|
view = copyObject(stmt->view); /* don't corrupt original command */
|
2010-12-13 18:34:26 +01:00
|
|
|
if (view->relpersistence == RELPERSISTENCE_PERMANENT
|
|
|
|
&& isViewOnTempTable(viewParse))
|
2005-02-02 07:36:02 +01:00
|
|
|
{
|
2010-12-13 18:34:26 +01:00
|
|
|
view->relpersistence = RELPERSISTENCE_TEMP;
|
2007-03-13 01:33:44 +01:00
|
|
|
ereport(NOTICE,
|
|
|
|
(errmsg("view \"%s\" will be a temporary view",
|
|
|
|
view->relname)));
|
2005-02-02 07:36:02 +01:00
|
|
|
}
|
2005-10-15 04:49:52 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
2002-03-22 03:56:37 +01:00
|
|
|
* Create the view relation
|
|
|
|
*
|
2005-11-22 19:17:34 +01:00
|
|
|
* NOTE: if it already exists and replace is false, the xact will be
|
|
|
|
* aborted.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2007-03-13 01:33:44 +01:00
|
|
|
viewOid = DefineVirtualRelation(view, viewParse->targetList,
|
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
|
|
|
stmt->replace, stmt->options);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* The relation we have just created is not visible to any other commands
|
|
|
|
* running with the same transaction & command id. So, increment the
|
|
|
|
* command id counter (but do NOT pfree any memory!!!!)
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* The range table of 'viewParse' does not contain entries for the "OLD"
|
|
|
|
* and "NEW" relations. So... add them!
|
2000-12-21 18:36:15 +01:00
|
|
|
*/
|
2002-03-22 03:56:37 +01:00
|
|
|
viewParse = UpdateRangeTableOfViewParse(viewOid, viewParse);
|
2000-12-21 18:36:15 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now create the rules associated with the view.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2007-08-27 05:36:08 +02:00
|
|
|
DefineViewRules(viewOid, viewParse, stmt->replace);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|