1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* utility.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* Contains functions which control the execution of the POSTGRES utility
|
|
|
|
* commands. At one time acted as an interface between the Lisp and C
|
|
|
|
* systems.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2015-01-06 17:43:47 +01:00
|
|
|
* Portions Copyright (c) 1996-2015, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/tcop/utility.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2009-02-02 20:31:40 +01:00
|
|
|
#include "access/reloptions.h"
|
2005-06-18 00:32:51 +02:00
|
|
|
#include "access/twophase.h"
|
2006-07-13 18:49:20 +02:00
|
|
|
#include "access/xact.h"
|
2014-11-06 12:52:08 +01:00
|
|
|
#include "access/xlog.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "catalog/catalog.h"
|
2002-03-26 20:17:02 +01:00
|
|
|
#include "catalog/namespace.h"
|
2006-07-31 03:16:38 +02:00
|
|
|
#include "catalog/toasting.h"
|
2003-06-27 16:45:32 +02:00
|
|
|
#include "commands/alter.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "commands/async.h"
|
|
|
|
#include "commands/cluster.h"
|
1999-10-26 05:12:39 +02:00
|
|
|
#include "commands/comment.h"
|
2011-02-12 14:54:13 +01:00
|
|
|
#include "commands/collationcmds.h"
|
2002-07-11 09:39:28 +02:00
|
|
|
#include "commands/conversioncmds.h"
|
2006-07-11 20:26:11 +02:00
|
|
|
#include "commands/copy.h"
|
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
|
|
|
#include "commands/createas.h"
|
1997-11-24 06:32:56 +01:00
|
|
|
#include "commands/dbcommands.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "commands/defrem.h"
|
2007-04-26 18:13:15 +02:00
|
|
|
#include "commands/discard.h"
|
2012-07-18 16:16:16 +02:00
|
|
|
#include "commands/event_trigger.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "commands/explain.h"
|
2011-02-08 22:08:41 +01:00
|
|
|
#include "commands/extension.h"
|
2013-03-04 01:23:31 +01:00
|
|
|
#include "commands/matview.h"
|
2002-04-15 07:22:04 +02:00
|
|
|
#include "commands/lockcmds.h"
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
#include "commands/policy.h"
|
2002-04-15 07:22:04 +02:00
|
|
|
#include "commands/portalcmds.h"
|
2002-08-27 06:55:12 +02:00
|
|
|
#include "commands/prepare.h"
|
1997-10-28 16:11:45 +01:00
|
|
|
#include "commands/proclang.h"
|
2002-04-15 07:22:04 +02:00
|
|
|
#include "commands/schemacmds.h"
|
2010-09-28 02:55:27 +02:00
|
|
|
#include "commands/seclabel.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "commands/sequence.h"
|
2002-04-15 07:22:04 +02:00
|
|
|
#include "commands/tablecmds.h"
|
2004-06-18 08:14:31 +02:00
|
|
|
#include "commands/tablespace.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "commands/trigger.h"
|
2002-12-06 06:00:34 +01:00
|
|
|
#include "commands/typecmds.h"
|
1999-12-20 02:19:58 +01:00
|
|
|
#include "commands/user.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "commands/vacuum.h"
|
|
|
|
#include "commands/view.h"
|
|
|
|
#include "miscadmin.h"
|
2007-06-24 00:12:52 +02:00
|
|
|
#include "parser/parse_utilcmd.h"
|
2004-05-30 00:48:23 +02:00
|
|
|
#include "postmaster/bgwriter.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "rewrite/rewriteDefine.h"
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "rewrite/rewriteRemove.h"
|
2004-02-10 02:55:27 +01:00
|
|
|
#include "storage/fd.h"
|
2003-05-06 22:26:28 +02:00
|
|
|
#include "tcop/pquery.h"
|
1996-11-11 05:54:54 +01:00
|
|
|
#include "tcop/utility.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "utils/acl.h"
|
2002-05-17 03:19:19 +02:00
|
|
|
#include "utils/guc.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "utils/syscache.h"
|
2004-05-30 00:48:23 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2009-12-15 21:04:49 +01:00
|
|
|
/* Hook for plugins to get control in ProcessUtility() */
|
|
|
|
ProcessUtility_hook_type ProcessUtility_hook = NULL;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
/* local function declarations */
|
|
|
|
static void ProcessUtilitySlow(Node *parsetree,
|
|
|
|
const char *queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilityContext context,
|
2013-04-28 05:11:28 +02:00
|
|
|
ParamListInfo params,
|
|
|
|
DestReceiver *dest,
|
2013-04-28 06:18:45 +02:00
|
|
|
char *completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
static void ExecDropStmt(DropStmt *stmt, bool isTopLevel);
|
|
|
|
|
2009-12-15 21:04:49 +01:00
|
|
|
|
2004-09-13 22:10:13 +02:00
|
|
|
/*
|
2007-02-20 18:32:18 +01:00
|
|
|
* CommandIsReadOnly: is an executable query read-only?
|
2004-09-13 22:10:13 +02:00
|
|
|
*
|
|
|
|
* This is a much stricter test than we apply for XactReadOnly mode;
|
|
|
|
* the query must be *in truth* read-only, because the caller wishes
|
|
|
|
* not to do CommandCounterIncrement for it.
|
2007-02-20 18:32:18 +01:00
|
|
|
*
|
|
|
|
* Note: currently no need to support Query nodes here
|
2004-09-13 22:10:13 +02:00
|
|
|
*/
|
|
|
|
bool
|
2007-02-20 18:32:18 +01:00
|
|
|
CommandIsReadOnly(Node *parsetree)
|
2004-09-13 22:10:13 +02:00
|
|
|
{
|
2007-02-20 18:32:18 +01:00
|
|
|
if (IsA(parsetree, PlannedStmt))
|
2004-09-13 22:10:13 +02:00
|
|
|
{
|
2007-02-20 18:32:18 +01:00
|
|
|
PlannedStmt *stmt = (PlannedStmt *) parsetree;
|
|
|
|
|
|
|
|
switch (stmt->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
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 (stmt->rowMarks != NIL)
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
return false; /* SELECT FOR [KEY] UPDATE/SHARE */
|
2011-02-26 00:56:23 +01:00
|
|
|
else if (stmt->hasModifyingCTE)
|
|
|
|
return false; /* data-modifying CTE */
|
2007-02-20 18:32:18 +01:00
|
|
|
else
|
|
|
|
return true;
|
|
|
|
case CMD_UPDATE:
|
|
|
|
case CMD_INSERT:
|
|
|
|
case CMD_DELETE:
|
|
|
|
return false;
|
|
|
|
default:
|
|
|
|
elog(WARNING, "unrecognized commandType: %d",
|
|
|
|
(int) stmt->commandType);
|
|
|
|
break;
|
|
|
|
}
|
2004-09-13 22:10:13 +02:00
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
/* For now, treat all utility commands as read/write */
|
2004-09-13 22:10:13 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* check_xact_readonly: is a utility command read-only?
|
|
|
|
*
|
|
|
|
* Here we use the loose rules of XactReadOnly mode: no permanent effects
|
|
|
|
* on the database are allowed.
|
|
|
|
*/
|
2003-01-10 23:03:30 +01:00
|
|
|
static void
|
|
|
|
check_xact_readonly(Node *parsetree)
|
|
|
|
{
|
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
|
|
|
/* Only perform the check if we have a reason to do so. */
|
|
|
|
if (!XactReadOnly && !IsInParallelMode())
|
2003-01-10 23:03:30 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Note: Commands that need to do more complicated checking are handled
|
2009-06-11 16:49:15 +02:00
|
|
|
* elsewhere, in particular COPY and plannable statements do their own
|
2015-05-24 03:35:49 +02:00
|
|
|
* checking. However they should all call PreventCommandIfReadOnly or
|
|
|
|
* PreventCommandIfParallelMode to actually throw the error.
|
2003-01-10 23:03:30 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
2005-07-31 19:19:22 +02:00
|
|
|
case T_AlterDatabaseStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_AlterDatabaseSetStmt:
|
|
|
|
case T_AlterDomainStmt:
|
2005-03-14 01:19:37 +01:00
|
|
|
case T_AlterFunctionStmt:
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_AlterRoleStmt:
|
|
|
|
case T_AlterRoleSetStmt:
|
2005-08-01 06:03:59 +02:00
|
|
|
case T_AlterObjectSchemaStmt:
|
2004-06-25 23:55:59 +02:00
|
|
|
case T_AlterOwnerStmt:
|
2015-07-14 17:17:55 +02:00
|
|
|
case T_AlterOperatorStmt:
|
2003-03-20 08:02:11 +01:00
|
|
|
case T_AlterSeqStmt:
|
2014-08-22 01:06:17 +02:00
|
|
|
case T_AlterTableMoveAllStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_AlterTableStmt:
|
2004-06-25 23:55:59 +02:00
|
|
|
case T_RenameStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_CommentStmt:
|
|
|
|
case T_DefineStmt:
|
|
|
|
case T_CreateCastStmt:
|
2012-07-18 16:16:16 +02:00
|
|
|
case T_CreateEventTrigStmt:
|
|
|
|
case T_AlterEventTrigStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_CreateConversionStmt:
|
|
|
|
case T_CreatedbStmt:
|
|
|
|
case T_CreateDomainStmt:
|
|
|
|
case T_CreateFunctionStmt:
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_CreateRoleStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_IndexStmt:
|
|
|
|
case T_CreatePLangStmt:
|
|
|
|
case T_CreateOpClassStmt:
|
2007-01-23 06:07:18 +01:00
|
|
|
case T_CreateOpFamilyStmt:
|
|
|
|
case T_AlterOpFamilyStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_RuleStmt:
|
|
|
|
case T_CreateSchemaStmt:
|
|
|
|
case T_CreateSeqStmt:
|
|
|
|
case T_CreateStmt:
|
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
|
|
|
case T_CreateTableAsStmt:
|
2013-03-04 01:23:31 +01:00
|
|
|
case T_RefreshMatViewStmt:
|
2004-06-18 08:14:31 +02:00
|
|
|
case T_CreateTableSpaceStmt:
|
2015-04-26 16:33:14 +02:00
|
|
|
case T_CreateTransformStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_CreateTrigStmt:
|
|
|
|
case T_CompositeTypeStmt:
|
2007-04-02 05:49:42 +02:00
|
|
|
case T_CreateEnumStmt:
|
2011-11-03 12:16:28 +01:00
|
|
|
case T_CreateRangeStmt:
|
2010-10-25 05:04:37 +02:00
|
|
|
case T_AlterEnumStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_ViewStmt:
|
|
|
|
case T_DropStmt:
|
|
|
|
case T_DropdbStmt:
|
2004-06-18 08:14:31 +02:00
|
|
|
case T_DropTableSpaceStmt:
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_DropRoleStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_GrantStmt:
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_GrantRoleStmt:
|
2009-10-05 21:24:49 +02:00
|
|
|
case T_AlterDefaultPrivilegesStmt:
|
2003-01-10 23:03:30 +01:00
|
|
|
case T_TruncateStmt:
|
2005-11-21 13:49:33 +01:00
|
|
|
case T_DropOwnedStmt:
|
|
|
|
case T_ReassignOwnedStmt:
|
2007-08-21 03:11:32 +02:00
|
|
|
case T_AlterTSDictionaryStmt:
|
|
|
|
case T_AlterTSConfigurationStmt:
|
2011-02-08 22:08:41 +01:00
|
|
|
case T_CreateExtensionStmt:
|
2011-02-12 03:25:20 +01:00
|
|
|
case T_AlterExtensionStmt:
|
2011-02-10 23:36:44 +01:00
|
|
|
case T_AlterExtensionContentsStmt:
|
2008-12-19 17:25:19 +01:00
|
|
|
case T_CreateFdwStmt:
|
|
|
|
case T_AlterFdwStmt:
|
|
|
|
case T_CreateForeignServerStmt:
|
|
|
|
case T_AlterForeignServerStmt:
|
|
|
|
case T_CreateUserMappingStmt:
|
|
|
|
case T_AlterUserMappingStmt:
|
|
|
|
case T_DropUserMappingStmt:
|
2010-01-05 22:54:00 +01:00
|
|
|
case T_AlterTableSpaceOptionsStmt:
|
2011-01-02 05:48:11 +01:00
|
|
|
case T_CreateForeignTableStmt:
|
2014-07-10 21:01:31 +02:00
|
|
|
case T_ImportForeignSchemaStmt:
|
2010-09-28 02:55:27 +02:00
|
|
|
case T_SecLabelStmt:
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandIfReadOnly(CreateCommandTag(parsetree));
|
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
|
|
|
PreventCommandIfParallelMode(CreateCommandTag(parsetree));
|
2003-01-10 23:03:30 +01:00
|
|
|
break;
|
|
|
|
default:
|
2003-07-22 21:00:12 +02:00
|
|
|
/* do nothing */
|
|
|
|
break;
|
2003-01-10 23:03:30 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
/*
|
|
|
|
* PreventCommandIfReadOnly: throw error if XactReadOnly
|
|
|
|
*
|
|
|
|
* This is useful mainly to ensure consistency of the error message wording;
|
|
|
|
* most callers have checked XactReadOnly for themselves.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PreventCommandIfReadOnly(const char *cmdname)
|
|
|
|
{
|
|
|
|
if (XactReadOnly)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_READ_ONLY_SQL_TRANSACTION),
|
2010-02-26 03:01:40 +01:00
|
|
|
/* translator: %s is name of a SQL command, eg CREATE */
|
2010-02-20 22:24:02 +01:00
|
|
|
errmsg("cannot execute %s in a read-only transaction",
|
|
|
|
cmdname)));
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* PreventCommandIfParallelMode: throw error if current (sub)transaction is
|
|
|
|
* in parallel mode.
|
|
|
|
*
|
|
|
|
* This is useful mainly to ensure consistency of the error message wording;
|
|
|
|
* most callers have checked IsInParallelMode() for themselves.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PreventCommandIfParallelMode(const char *cmdname)
|
|
|
|
{
|
|
|
|
if (IsInParallelMode())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
|
|
|
|
/* translator: %s is name of a SQL command, eg CREATE */
|
|
|
|
errmsg("cannot execute %s during a parallel operation",
|
|
|
|
cmdname)));
|
|
|
|
}
|
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
/*
|
|
|
|
* PreventCommandDuringRecovery: throw error if RecoveryInProgress
|
|
|
|
*
|
|
|
|
* The majority of operations that are unsafe in a Hot Standby slave
|
2014-05-06 18:12:18 +02:00
|
|
|
* will be rejected by XactReadOnly tests. However there are a few
|
2010-02-20 22:24:02 +01:00
|
|
|
* commands that are allowed in "read-only" xacts but cannot be allowed
|
|
|
|
* in Hot Standby mode. Those commands should call this function.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
PreventCommandDuringRecovery(const char *cmdname)
|
|
|
|
{
|
|
|
|
if (RecoveryInProgress())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_READ_ONLY_SQL_TRANSACTION),
|
2010-02-26 03:01:40 +01:00
|
|
|
/* translator: %s is name of a SQL command, eg CREATE */
|
2010-02-20 22:24:02 +01:00
|
|
|
errmsg("cannot execute %s during recovery",
|
|
|
|
cmdname)));
|
|
|
|
}
|
2003-01-10 23:03:30 +01:00
|
|
|
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
/*
|
|
|
|
* CheckRestrictedOperation: throw error for hazardous command if we're
|
|
|
|
* inside a security restriction context.
|
|
|
|
*
|
|
|
|
* This is needed to protect session-local state for which there is not any
|
|
|
|
* better-defined protection mechanism, such as ownership.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
CheckRestrictedOperation(const char *cmdname)
|
|
|
|
{
|
|
|
|
if (InSecurityRestrictedOperation())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
2010-02-26 03:01:40 +01:00
|
|
|
/* translator: %s is name of a SQL command, eg PREPARE */
|
|
|
|
errmsg("cannot execute %s within security-restricted operation",
|
|
|
|
cmdname)));
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-02-26 23:47:12 +01:00
|
|
|
/*
|
|
|
|
* ProcessUtility
|
1997-09-07 07:04:48 +02:00
|
|
|
* general utility function invoker
|
2002-02-26 23:47:12 +01:00
|
|
|
*
|
|
|
|
* parsetree: the parse tree for the utility statement
|
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement. That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text. Fix it to copy the source text over
from the cached plan. Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.
There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
ProcessUtility((Node *) atstmt,
"(generated ALTER TABLE ADD FOREIGN KEY command)",
NULL, false, None_Receiver, NULL);
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
ITAGAKI Takahiro and Tom Lane
2008-07-18 22:26:06 +02:00
|
|
|
* queryString: original source text of command
|
2013-04-28 06:18:45 +02:00
|
|
|
* context: identifies source of statement (toplevel client command,
|
|
|
|
* non-toplevel client command, subcommand of a larger utility command)
|
2005-11-29 02:25:50 +01:00
|
|
|
* params: parameters to use during execution
|
2002-02-26 23:47:12 +01:00
|
|
|
* dest: where to send results
|
|
|
|
* completionTag: points to a buffer of size COMPLETION_TAG_BUFSIZE
|
|
|
|
* in which to store a command completion status string.
|
|
|
|
*
|
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement. That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text. Fix it to copy the source text over
from the cached plan. Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.
There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
ProcessUtility((Node *) atstmt,
"(generated ALTER TABLE ADD FOREIGN KEY command)",
NULL, false, None_Receiver, NULL);
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
ITAGAKI Takahiro and Tom Lane
2008-07-18 22:26:06 +02:00
|
|
|
* Notes: as of PG 8.4, caller MUST supply a queryString; it is not
|
|
|
|
* allowed anymore to pass NULL. (If you really don't have source text,
|
|
|
|
* you can pass a constant string, perhaps "(query not available)".)
|
|
|
|
*
|
2004-09-13 22:10:13 +02:00
|
|
|
* completionTag is only set nonempty if we want to return a nondefault status.
|
2002-02-26 23:47:12 +01:00
|
|
|
*
|
|
|
|
* completionTag may be NULL if caller doesn't want a status string.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
void
|
1998-02-26 05:46:47 +01:00
|
|
|
ProcessUtility(Node *parsetree,
|
2007-03-13 01:33:44 +01:00
|
|
|
const char *queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilityContext context,
|
2004-08-02 03:30:51 +02:00
|
|
|
ParamListInfo params,
|
2003-05-06 22:26:28 +02:00
|
|
|
DestReceiver *dest,
|
2013-04-28 06:18:45 +02:00
|
|
|
char *completionTag)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2009-06-11 16:49:15 +02:00
|
|
|
Assert(queryString != NULL); /* required as of 8.4 */
|
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement. That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text. Fix it to copy the source text over
from the cached plan. Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.
There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
ProcessUtility((Node *) atstmt,
"(generated ALTER TABLE ADD FOREIGN KEY command)",
NULL, false, None_Receiver, NULL);
We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.
ITAGAKI Takahiro and Tom Lane
2008-07-18 22:26:06 +02:00
|
|
|
|
2009-12-15 21:04:49 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* We provide a function hook variable that lets loadable plugins get
|
|
|
|
* control when ProcessUtility is called. Such a plugin would normally
|
|
|
|
* call standard_ProcessUtility().
|
2009-12-15 21:04:49 +01:00
|
|
|
*/
|
|
|
|
if (ProcessUtility_hook)
|
2013-04-28 06:18:45 +02:00
|
|
|
(*ProcessUtility_hook) (parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2009-12-15 21:04:49 +01:00
|
|
|
else
|
2013-04-28 06:18:45 +02:00
|
|
|
standard_ProcessUtility(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2009-12-15 21:04:49 +01:00
|
|
|
}
|
|
|
|
|
Add sql_drop event for event triggers
This event takes place just before ddl_command_end, and is fired if and
only if at least one object has been dropped by the command. (For
instance, DROP TABLE IF EXISTS of a table that does not in fact exist
will not lead to such a trigger firing). Commands that drop multiple
objects (such as DROP SCHEMA or DROP OWNED BY) will cause a single event
to fire. Some firings might be surprising, such as
ALTER TABLE DROP COLUMN.
The trigger is fired after the drop has taken place, because that has
been deemed the safest design, to avoid exposing possibly-inconsistent
internal state (system catalogs as well as current transaction) to the
user function code. This means that careful tracking of object
identification is required during the object removal phase.
Like other currently existing events, there is support for tag
filtering.
To support the new event, add a new pg_event_trigger_dropped_objects()
set-returning function, which returns a set of rows comprising the
objects affected by the command. This is to be used within the user
function code, and is mostly modelled after the recently introduced
pg_identify_object() function.
Catalog version bumped due to the new function.
Dimitri Fontaine and Álvaro Herrera
Review by Robert Haas, Tom Lane
2013-03-27 20:02:10 +01:00
|
|
|
/*
|
2013-04-28 05:11:28 +02:00
|
|
|
* standard_ProcessUtility itself deals only with utility commands for
|
|
|
|
* which we do not provide event trigger support. Commands that do have
|
|
|
|
* such support are passed down to ProcessUtilitySlow, which contains the
|
|
|
|
* necessary infrastructure for such triggers.
|
|
|
|
*
|
|
|
|
* This division is not just for performance: it's critical that the
|
|
|
|
* event trigger code not be invoked when doing START TRANSACTION for
|
|
|
|
* example, because we might need to refresh the event trigger cache,
|
|
|
|
* which requires being in a valid transaction.
|
Add sql_drop event for event triggers
This event takes place just before ddl_command_end, and is fired if and
only if at least one object has been dropped by the command. (For
instance, DROP TABLE IF EXISTS of a table that does not in fact exist
will not lead to such a trigger firing). Commands that drop multiple
objects (such as DROP SCHEMA or DROP OWNED BY) will cause a single event
to fire. Some firings might be surprising, such as
ALTER TABLE DROP COLUMN.
The trigger is fired after the drop has taken place, because that has
been deemed the safest design, to avoid exposing possibly-inconsistent
internal state (system catalogs as well as current transaction) to the
user function code. This means that careful tracking of object
identification is required during the object removal phase.
Like other currently existing events, there is support for tag
filtering.
To support the new event, add a new pg_event_trigger_dropped_objects()
set-returning function, which returns a set of rows comprising the
objects affected by the command. This is to be used within the user
function code, and is mostly modelled after the recently introduced
pg_identify_object() function.
Catalog version bumped due to the new function.
Dimitri Fontaine and Álvaro Herrera
Review by Robert Haas, Tom Lane
2013-03-27 20:02:10 +01:00
|
|
|
*/
|
2009-12-15 21:04:49 +01:00
|
|
|
void
|
|
|
|
standard_ProcessUtility(Node *parsetree,
|
|
|
|
const char *queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilityContext context,
|
2009-12-15 21:04:49 +01:00
|
|
|
ParamListInfo params,
|
|
|
|
DestReceiver *dest,
|
2013-04-28 06:18:45 +02:00
|
|
|
char *completionTag)
|
2009-12-15 21:04:49 +01:00
|
|
|
{
|
2012-07-20 17:38:47 +02:00
|
|
|
bool isTopLevel = (context == PROCESS_UTILITY_TOPLEVEL);
|
|
|
|
|
2003-01-10 23:03:30 +01:00
|
|
|
check_xact_readonly(parsetree);
|
|
|
|
|
2002-02-26 23:47:12 +01:00
|
|
|
if (completionTag)
|
|
|
|
completionTag[0] = '\0';
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
switch (nodeTag(parsetree))
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
/*
|
2003-02-19 04:59:02 +01:00
|
|
|
* ******************** transactions ********************
|
1997-09-08 04:41:22 +02:00
|
|
|
*/
|
|
|
|
case T_TransactionStmt:
|
|
|
|
{
|
|
|
|
TransactionStmt *stmt = (TransactionStmt *) parsetree;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
switch (stmt->kind)
|
1997-09-08 04:41:22 +02:00
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* START TRANSACTION, as defined by SQL99: Identical
|
|
|
|
* to BEGIN. Same code for both.
|
2004-08-29 07:07:03 +02:00
|
|
|
*/
|
2003-02-10 05:44:47 +01:00
|
|
|
case TRANS_STMT_BEGIN:
|
|
|
|
case TRANS_STMT_START:
|
2002-08-04 06:31:44 +02:00
|
|
|
{
|
2004-08-12 23:00:34 +02:00
|
|
|
ListCell *lc;
|
2002-08-04 06:31:44 +02:00
|
|
|
|
2004-08-12 23:00:34 +02:00
|
|
|
BeginTransactionBlock();
|
|
|
|
foreach(lc, stmt->options)
|
2002-08-04 06:31:44 +02:00
|
|
|
{
|
2004-08-12 23:00:34 +02:00
|
|
|
DefElem *item = (DefElem *) lfirst(lc);
|
|
|
|
|
|
|
|
if (strcmp(item->defname, "transaction_isolation") == 0)
|
|
|
|
SetPGVariable("transaction_isolation",
|
|
|
|
list_make1(item->arg),
|
2005-06-18 00:32:51 +02:00
|
|
|
true);
|
2004-08-12 23:00:34 +02:00
|
|
|
else if (strcmp(item->defname, "transaction_read_only") == 0)
|
|
|
|
SetPGVariable("transaction_read_only",
|
|
|
|
list_make1(item->arg),
|
2005-06-18 00:32:51 +02:00
|
|
|
true);
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
else if (strcmp(item->defname, "transaction_deferrable") == 0)
|
|
|
|
SetPGVariable("transaction_deferrable",
|
|
|
|
list_make1(item->arg),
|
|
|
|
true);
|
2002-08-04 06:31:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
case TRANS_STMT_COMMIT:
|
2004-07-27 07:11:48 +02:00
|
|
|
if (!EndTransactionBlock())
|
|
|
|
{
|
|
|
|
/* report unsuccessful commit in completionTag */
|
|
|
|
if (completionTag)
|
|
|
|
strcpy(completionTag, "ROLLBACK");
|
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
case TRANS_STMT_PREPARE:
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("PREPARE TRANSACTION");
|
2005-06-18 00:32:51 +02:00
|
|
|
if (!PrepareTransactionBlock(stmt->gid))
|
|
|
|
{
|
|
|
|
/* report unsuccessful commit in completionTag */
|
|
|
|
if (completionTag)
|
|
|
|
strcpy(completionTag, "ROLLBACK");
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_COMMIT_PREPARED:
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "COMMIT PREPARED");
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("COMMIT PREPARED");
|
2005-06-18 00:32:51 +02:00
|
|
|
FinishPreparedTransaction(stmt->gid, true);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_ROLLBACK_PREPARED:
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "ROLLBACK PREPARED");
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("ROLLBACK PREPARED");
|
2005-06-18 00:32:51 +02:00
|
|
|
FinishPreparedTransaction(stmt->gid, false);
|
|
|
|
break;
|
|
|
|
|
2003-02-10 05:44:47 +01:00
|
|
|
case TRANS_STMT_ROLLBACK:
|
1997-09-08 04:41:22 +02:00
|
|
|
UserAbortTransactionBlock();
|
|
|
|
break;
|
2004-07-27 07:11:48 +02:00
|
|
|
|
|
|
|
case TRANS_STMT_SAVEPOINT:
|
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
ListCell *cell;
|
|
|
|
char *name = NULL;
|
2004-07-27 07:11:48 +02:00
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
RequireTransactionChain(isTopLevel, "SAVEPOINT");
|
2004-07-27 07:11:48 +02:00
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
foreach(cell, stmt->options)
|
2004-07-27 07:11:48 +02:00
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
DefElem *elem = lfirst(cell);
|
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
if (strcmp(elem->defname, "savepoint_name") == 0)
|
|
|
|
name = strVal(elem->arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
Assert(PointerIsValid(name));
|
|
|
|
|
|
|
|
DefineSavepoint(name);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_RELEASE:
|
2007-03-13 01:33:44 +01:00
|
|
|
RequireTransactionChain(isTopLevel, "RELEASE SAVEPOINT");
|
2004-07-27 07:11:48 +02:00
|
|
|
ReleaseSavepoint(stmt->options);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_ROLLBACK_TO:
|
2007-03-13 01:33:44 +01:00
|
|
|
RequireTransactionChain(isTopLevel, "ROLLBACK TO SAVEPOINT");
|
2004-07-27 07:11:48 +02:00
|
|
|
RollbackToSavepoint(stmt->options);
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
/*
|
2004-08-29 07:07:03 +02:00
|
|
|
* CommitTransactionCommand is in charge of
|
|
|
|
* re-defining the savepoint again
|
2004-07-27 07:11:48 +02:00
|
|
|
*/
|
|
|
|
break;
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
2003-03-10 04:53:52 +01:00
|
|
|
* Portal (cursor) manipulation
|
2007-04-28 00:05:49 +02:00
|
|
|
*
|
|
|
|
* Note: DECLARE CURSOR is processed mostly as a SELECT, and
|
|
|
|
* therefore what we will get here is a PlannedStmt not a bare
|
|
|
|
* DeclareCursorStmt.
|
1997-09-08 04:41:22 +02:00
|
|
|
*/
|
2007-04-28 00:05:49 +02:00
|
|
|
case T_PlannedStmt:
|
|
|
|
{
|
|
|
|
PlannedStmt *stmt = (PlannedStmt *) parsetree;
|
|
|
|
|
|
|
|
if (stmt->utilityStmt == NULL ||
|
|
|
|
!IsA(stmt->utilityStmt, DeclareCursorStmt))
|
|
|
|
elog(ERROR, "non-DECLARE CURSOR PlannedStmt passed to ProcessUtility");
|
|
|
|
PerformCursorOpen(stmt, params, queryString, isTopLevel);
|
|
|
|
}
|
2003-03-10 04:53:52 +01:00
|
|
|
break;
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_ClosePortalStmt:
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
ClosePortalStmt *stmt = (ClosePortalStmt *) parsetree;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
CheckRestrictedOperation("CLOSE");
|
2003-03-10 04:53:52 +01:00
|
|
|
PerformPortalClose(stmt->portalname);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_FetchStmt:
|
2003-03-11 20:40:24 +01:00
|
|
|
PerformPortalFetch((FetchStmt *) parsetree, dest,
|
|
|
|
completionTag);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_DoStmt:
|
|
|
|
ExecuteDoStmt((DoStmt *) parsetree);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
case T_CreateTableSpaceStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "CREATE TABLESPACE");
|
2004-06-18 08:14:31 +02:00
|
|
|
CreateTableSpace((CreateTableSpaceStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropTableSpaceStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "DROP TABLESPACE");
|
2004-06-18 08:14:31 +02:00
|
|
|
DropTableSpace((DropTableSpaceStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
2010-01-05 22:54:00 +01:00
|
|
|
case T_AlterTableSpaceOptionsStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2010-01-05 22:54:00 +01:00
|
|
|
AlterTableSpaceOptions((AlterTableSpaceOptionsStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
1999-09-30 03:12:36 +02:00
|
|
|
case T_TruncateStmt:
|
2006-03-03 04:30:54 +01:00
|
|
|
ExecuteTruncate((TruncateStmt *) parsetree);
|
1999-09-23 19:03:39 +02:00
|
|
|
break;
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_CopyStmt:
|
2006-03-03 20:54:10 +01:00
|
|
|
{
|
2007-03-13 01:33:44 +01:00
|
|
|
uint64 processed;
|
2006-03-03 20:54:10 +01:00
|
|
|
|
2012-12-29 13:55:37 +01:00
|
|
|
DoCopy((CopyStmt *) parsetree, queryString, &processed);
|
2006-03-03 20:54:10 +01:00
|
|
|
if (completionTag)
|
|
|
|
snprintf(completionTag, COMPLETION_TAG_BUFSIZE,
|
|
|
|
"COPY " UINT64_FORMAT, processed);
|
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-08-27 06:55:12 +02:00
|
|
|
case T_PrepareStmt:
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
CheckRestrictedOperation("PREPARE");
|
2007-03-13 01:33:44 +01:00
|
|
|
PrepareQuery((PrepareStmt *) parsetree, queryString);
|
2002-08-27 06:55:12 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExecuteStmt:
|
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
|
|
|
ExecuteQuery((ExecuteStmt *) parsetree, NULL,
|
|
|
|
queryString, params,
|
2005-11-29 02:25:50 +01:00
|
|
|
dest, completionTag);
|
2002-08-27 06:55:12 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeallocateStmt:
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
CheckRestrictedOperation("DEALLOCATE");
|
2002-08-27 06:55:12 +02:00
|
|
|
DeallocateQuery((DeallocateStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_GrantRoleStmt:
|
2013-04-28 05:11:28 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-06-28 07:09:14 +02:00
|
|
|
GrantRole((GrantRoleStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_CreatedbStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "CREATE DATABASE");
|
2002-07-01 17:27:56 +02:00
|
|
|
createdb((CreatedbStmt *) parsetree);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
case T_AlterDatabaseStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2008-11-07 19:25:07 +01:00
|
|
|
AlterDatabase((AlterDatabaseStmt *) parsetree, isTopLevel);
|
2005-07-31 19:19:22 +02:00
|
|
|
break;
|
|
|
|
|
2002-03-01 23:45:19 +01:00
|
|
|
case T_AlterDatabaseSetStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2002-07-01 17:27:56 +02:00
|
|
|
AlterDatabaseSet((AlterDatabaseSetStmt *) parsetree);
|
2002-03-01 23:45:19 +01:00
|
|
|
break;
|
|
|
|
|
1999-12-10 04:56:14 +01:00
|
|
|
case T_DropdbStmt:
|
1997-09-08 04:41:22 +02:00
|
|
|
{
|
1999-12-10 04:56:14 +01:00
|
|
|
DropdbStmt *stmt = (DropdbStmt *) parsetree;
|
1997-04-02 20:24:52 +02:00
|
|
|
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2007-03-13 01:33:44 +01:00
|
|
|
PreventTransactionChain(isTopLevel, "DROP DATABASE");
|
2005-11-22 16:24:18 +01:00
|
|
|
dropdb(stmt->dbname, stmt->missing_ok);
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
/* Query-level asynchronous notification */
|
|
|
|
case T_NotifyStmt:
|
|
|
|
{
|
|
|
|
NotifyStmt *stmt = (NotifyStmt *) parsetree;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("NOTIFY");
|
2010-02-16 23:34:57 +01:00
|
|
|
Async_Notify(stmt->conditionname, stmt->payload);
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_ListenStmt:
|
|
|
|
{
|
|
|
|
ListenStmt *stmt = (ListenStmt *) parsetree;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("LISTEN");
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
CheckRestrictedOperation("LISTEN");
|
2008-09-01 22:42:46 +02:00
|
|
|
Async_Listen(stmt->conditionname);
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-08-25 23:37:08 +02:00
|
|
|
case T_UnlistenStmt:
|
|
|
|
{
|
|
|
|
UnlistenStmt *stmt = (UnlistenStmt *) parsetree;
|
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
PreventCommandDuringRecovery("UNLISTEN");
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
CheckRestrictedOperation("UNLISTEN");
|
2008-09-01 22:42:46 +02:00
|
|
|
if (stmt->conditionname)
|
|
|
|
Async_Unlisten(stmt->conditionname);
|
2008-08-30 03:39:14 +02:00
|
|
|
else
|
|
|
|
Async_UnlistenAll();
|
1998-08-25 23:37:08 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_LoadStmt:
|
|
|
|
{
|
|
|
|
LoadStmt *stmt = (LoadStmt *) parsetree;
|
|
|
|
|
1999-05-25 18:15:34 +02:00
|
|
|
closeAllVfds(); /* probably not necessary... */
|
2006-08-15 20:26:59 +02:00
|
|
|
/* Allowed names are restricted if you're not superuser */
|
|
|
|
load_file(stmt->filename, !superuser());
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_ClusterStmt:
|
2010-02-20 22:24:02 +01:00
|
|
|
/* we choose to allow this during "read only" transactions */
|
|
|
|
PreventCommandDuringRecovery("CLUSTER");
|
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
|
|
|
/* forbidden in parallel mode due to CommandIsReadOnly */
|
2007-03-13 01:33:44 +01:00
|
|
|
cluster((ClusterStmt *) parsetree, isTopLevel);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VacuumStmt:
|
2012-10-08 13:17:27 +02:00
|
|
|
{
|
|
|
|
VacuumStmt *stmt = (VacuumStmt *) parsetree;
|
|
|
|
|
|
|
|
/* we choose to allow this during "read only" transactions */
|
|
|
|
PreventCommandDuringRecovery((stmt->options & VACOPT_VACUUM) ?
|
|
|
|
"VACUUM" : "ANALYZE");
|
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
|
|
|
/* forbidden in parallel mode due to CommandIsReadOnly */
|
2015-03-18 15:52:33 +01:00
|
|
|
ExecVacuum(stmt, isTopLevel);
|
2012-10-08 13:17:27 +02:00
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExplainStmt:
|
2007-03-13 01:33:44 +01:00
|
|
|
ExplainQuery((ExplainStmt *) parsetree, queryString, params, dest);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
case T_AlterSystemStmt:
|
|
|
|
PreventTransactionChain(isTopLevel, "ALTER SYSTEM");
|
|
|
|
AlterSystemSetConfigFile((AlterSystemStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
case T_VariableSetStmt:
|
2013-10-04 19:50:28 +02:00
|
|
|
ExecSetVariableStmt((VariableSetStmt *) parsetree, isTopLevel);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VariableShowStmt:
|
|
|
|
{
|
|
|
|
VariableShowStmt *n = (VariableShowStmt *) parsetree;
|
|
|
|
|
2003-05-06 22:26:28 +02:00
|
|
|
GetPGVariable(n->name, dest);
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
case T_DiscardStmt:
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
/* should we allow DISCARD PLANS? */
|
|
|
|
CheckRestrictedOperation("DISCARD");
|
2007-04-26 18:13:15 +02:00
|
|
|
DiscardCommand((DiscardStmt *) parsetree, isTopLevel);
|
|
|
|
break;
|
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
case T_CreateEventTrigStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers on event triggers */
|
2012-07-18 16:16:16 +02:00
|
|
|
CreateEventTrigger((CreateEventTrigStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterEventTrigStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers on event triggers */
|
2012-07-18 16:16:16 +02:00
|
|
|
AlterEventTrigger((AlterEventTrigStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
2002-03-19 03:18:25 +01:00
|
|
|
/*
|
2005-06-28 07:09:14 +02:00
|
|
|
* ******************************** ROLE statements ****
|
2002-03-19 03:18:25 +01:00
|
|
|
*/
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_CreateRoleStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-06-28 07:09:14 +02:00
|
|
|
CreateRole((CreateRoleStmt *) parsetree);
|
1998-02-26 05:46:47 +01:00
|
|
|
break;
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_AlterRoleStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-06-28 07:09:14 +02:00
|
|
|
AlterRole((AlterRoleStmt *) parsetree);
|
1998-02-26 05:46:47 +01:00
|
|
|
break;
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_AlterRoleSetStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-06-28 07:09:14 +02:00
|
|
|
AlterRoleSet((AlterRoleSetStmt *) parsetree);
|
2002-03-01 23:45:19 +01:00
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_DropRoleStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-06-28 07:09:14 +02:00
|
|
|
DropRole((DropRoleStmt *) parsetree);
|
1998-02-26 05:46:47 +01:00
|
|
|
break;
|
1997-12-04 01:28:15 +01:00
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
case T_ReassignOwnedStmt:
|
2012-07-20 17:38:47 +02:00
|
|
|
/* no event triggers for global objects */
|
2005-11-21 13:49:33 +01:00
|
|
|
ReassignOwnedObjects((ReassignOwnedStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
1998-12-18 10:10:39 +01:00
|
|
|
case T_LockStmt:
|
2009-06-11 16:49:15 +02:00
|
|
|
|
2008-11-04 01:57:19 +01:00
|
|
|
/*
|
|
|
|
* Since the lock would just get dropped immediately, LOCK TABLE
|
|
|
|
* outside a transaction block is presumed to be user error.
|
|
|
|
*/
|
|
|
|
RequireTransactionChain(isTopLevel, "LOCK TABLE");
|
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
|
|
|
/* forbidden in parallel mode due to CommandIsReadOnly */
|
1998-12-18 10:10:39 +01:00
|
|
|
LockTableCommand((LockStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
1999-09-29 18:06:40 +02:00
|
|
|
case T_ConstraintsSetStmt:
|
2013-11-26 01:19:40 +01:00
|
|
|
WarnNoTransactionChain(isTopLevel, "SET CONSTRAINTS");
|
2004-09-10 20:40:09 +02:00
|
|
|
AfterTriggerSetState((ConstraintsSetStmt *) parsetree);
|
1999-09-29 18:06:40 +02:00
|
|
|
break;
|
|
|
|
|
2000-11-05 23:50:21 +01:00
|
|
|
case T_CheckPointStmt:
|
2002-09-27 00:58:34 +02:00
|
|
|
if (!superuser())
|
2003-07-22 21:00:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
2003-08-01 02:15:26 +02:00
|
|
|
errmsg("must be superuser to do CHECKPOINT")));
|
2010-02-26 03:01:40 +01:00
|
|
|
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
/*
|
|
|
|
* You might think we should have a PreventCommandDuringRecovery()
|
2010-02-26 03:01:40 +01:00
|
|
|
* here, but we interpret a CHECKPOINT command during recovery as
|
|
|
|
* a request for a restartpoint instead. We allow this since it
|
|
|
|
* can be a useful way of reducing switchover time when using
|
|
|
|
* various forms of replication.
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
*/
|
|
|
|
RequestCheckpoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_WAIT |
|
2010-02-20 22:24:02 +01:00
|
|
|
(RecoveryInProgress() ? 0 : CHECKPOINT_FORCE));
|
2000-11-05 23:50:21 +01:00
|
|
|
break;
|
|
|
|
|
2000-02-18 10:30:20 +01:00
|
|
|
case T_ReindexStmt:
|
|
|
|
{
|
|
|
|
ReindexStmt *stmt = (ReindexStmt *) parsetree;
|
|
|
|
|
2010-02-20 22:24:02 +01:00
|
|
|
/* we choose to allow this during "read only" transactions */
|
|
|
|
PreventCommandDuringRecovery("REINDEX");
|
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
|
|
|
/* forbidden in parallel mode due to CommandIsReadOnly */
|
2003-02-10 05:44:47 +01:00
|
|
|
switch (stmt->kind)
|
2000-02-18 10:30:20 +01:00
|
|
|
{
|
2014-12-08 16:28:00 +01:00
|
|
|
case REINDEX_OBJECT_INDEX:
|
2015-05-15 13:09:57 +02:00
|
|
|
ReindexIndex(stmt->relation, stmt->options);
|
2000-02-18 10:30:20 +01:00
|
|
|
break;
|
2014-12-08 16:28:00 +01:00
|
|
|
case REINDEX_OBJECT_TABLE:
|
2015-05-15 13:09:57 +02:00
|
|
|
ReindexTable(stmt->relation, stmt->options);
|
2000-02-18 10:30:20 +01:00
|
|
|
break;
|
2014-12-08 16:28:00 +01:00
|
|
|
case REINDEX_OBJECT_SCHEMA:
|
|
|
|
case REINDEX_OBJECT_SYSTEM:
|
|
|
|
case REINDEX_OBJECT_DATABASE:
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-03-13 01:33:44 +01:00
|
|
|
/*
|
2007-11-15 22:14:46 +01:00
|
|
|
* This cannot run inside a user transaction block; if
|
|
|
|
* we were inside a transaction, then its commit- and
|
|
|
|
* start-transaction-command calls would not have the
|
|
|
|
* intended effect!
|
2007-03-13 01:33:44 +01:00
|
|
|
*/
|
|
|
|
PreventTransactionChain(isTopLevel,
|
2015-03-08 16:51:04 +01:00
|
|
|
(stmt->kind == REINDEX_OBJECT_SCHEMA) ? "REINDEX SCHEMA" :
|
|
|
|
(stmt->kind == REINDEX_OBJECT_SYSTEM) ? "REINDEX SYSTEM" :
|
|
|
|
"REINDEX DATABASE");
|
2015-05-15 13:09:57 +02:00
|
|
|
ReindexMultipleTables(stmt->name, stmt->kind, stmt->options);
|
2000-02-18 10:30:20 +01:00
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
default:
|
2003-07-22 21:00:12 +02:00
|
|
|
elog(ERROR, "unrecognized object type: %d",
|
|
|
|
(int) stmt->kind);
|
|
|
|
break;
|
2000-02-18 10:30:20 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2000-04-12 19:17:23 +02:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
/*
|
|
|
|
* The following statements are supported by Event Triggers only
|
|
|
|
* in some cases, so we "fast path" them in the other cases.
|
|
|
|
*/
|
2002-07-11 09:39:28 +02:00
|
|
|
|
2015-02-23 18:22:42 +01:00
|
|
|
case T_GrantStmt:
|
|
|
|
{
|
|
|
|
GrantStmt *stmt = (GrantStmt *) parsetree;
|
|
|
|
|
|
|
|
if (EventTriggerSupportsGrantObjectType(stmt->objtype))
|
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
|
|
|
else
|
|
|
|
ExecuteGrantStmt((GrantStmt *) parsetree);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_DropStmt:
|
|
|
|
{
|
|
|
|
DropStmt *stmt = (DropStmt *) parsetree;
|
2002-07-19 01:11:32 +02:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
if (EventTriggerSupportsObjectType(stmt->removeType))
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
else
|
|
|
|
ExecDropStmt(stmt, isTopLevel);
|
|
|
|
}
|
2002-07-30 00:14:11 +02:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_RenameStmt:
|
|
|
|
{
|
|
|
|
RenameStmt *stmt = (RenameStmt *) parsetree;
|
2007-01-23 06:07:18 +01:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
if (EventTriggerSupportsObjectType(stmt->renameType))
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
else
|
|
|
|
ExecRenameStmt(stmt);
|
|
|
|
}
|
2007-01-23 06:07:18 +01:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_AlterObjectSchemaStmt:
|
|
|
|
{
|
|
|
|
AlterObjectSchemaStmt *stmt = (AlterObjectSchemaStmt *) parsetree;
|
|
|
|
|
|
|
|
if (EventTriggerSupportsObjectType(stmt->objectType))
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
else
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
ExecAlterObjectSchemaStmt(stmt, NULL);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
2007-08-21 03:11:32 +02:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_AlterOwnerStmt:
|
|
|
|
{
|
|
|
|
AlterOwnerStmt *stmt = (AlterOwnerStmt *) parsetree;
|
|
|
|
|
|
|
|
if (EventTriggerSupportsObjectType(stmt->objectType))
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
else
|
|
|
|
ExecAlterOwnerStmt(stmt);
|
|
|
|
}
|
2007-08-21 03:11:32 +02:00
|
|
|
break;
|
|
|
|
|
2015-02-23 18:22:42 +01:00
|
|
|
case T_CommentStmt:
|
|
|
|
{
|
|
|
|
CommentStmt *stmt = (CommentStmt *) parsetree;
|
|
|
|
|
|
|
|
if (EventTriggerSupportsObjectType(stmt->objtype))
|
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
|
|
|
else
|
|
|
|
CommentObject((CommentStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case T_SecLabelStmt:
|
|
|
|
{
|
|
|
|
SecLabelStmt *stmt = (SecLabelStmt *) parsetree;
|
|
|
|
|
|
|
|
if (EventTriggerSupportsObjectType(stmt->objtype))
|
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
|
|
|
else
|
|
|
|
ExecSecLabelStmt(stmt);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
default:
|
2013-04-28 05:11:28 +02:00
|
|
|
/* All other statement types have event trigger support */
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilitySlow(parsetree, queryString,
|
|
|
|
context, params,
|
|
|
|
dest, completionTag);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-04-02 20:24:52 +02:00
|
|
|
}
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The "Slow" variant of ProcessUtility should only receive statements
|
|
|
|
* supported by the event triggers facility. Therefore, we always
|
|
|
|
* perform the trigger support calls if the context allows it.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ProcessUtilitySlow(Node *parsetree,
|
|
|
|
const char *queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
ProcessUtilityContext context,
|
2013-04-28 05:11:28 +02:00
|
|
|
ParamListInfo params,
|
|
|
|
DestReceiver *dest,
|
2013-04-28 06:18:45 +02:00
|
|
|
char *completionTag)
|
2013-04-28 05:11:28 +02:00
|
|
|
{
|
|
|
|
bool isTopLevel = (context == PROCESS_UTILITY_TOPLEVEL);
|
|
|
|
bool isCompleteQuery = (context <= PROCESS_UTILITY_QUERY);
|
|
|
|
bool needCleanup;
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
bool commandCollected = false;
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
ObjectAddress address;
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
ObjectAddress secondaryObject = InvalidObjectAddress;
|
2013-04-28 05:11:28 +02:00
|
|
|
|
|
|
|
/* All event trigger calls are done only when isCompleteQuery is true */
|
|
|
|
needCleanup = isCompleteQuery && EventTriggerBeginCompleteQuery();
|
|
|
|
|
|
|
|
/* PG_TRY block is to ensure we call EventTriggerEndCompleteQuery */
|
|
|
|
PG_TRY();
|
|
|
|
{
|
|
|
|
if (isCompleteQuery)
|
|
|
|
EventTriggerDDLCommandStart(parsetree);
|
|
|
|
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* relation and attribute manipulation
|
|
|
|
*/
|
|
|
|
case T_CreateSchemaStmt:
|
|
|
|
CreateSchemaCommand((CreateSchemaStmt *) parsetree,
|
|
|
|
queryString);
|
2015-05-24 03:35:49 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
|
|
|
* EventTriggerCollectSimpleCommand called by
|
|
|
|
* CreateSchemaCommand
|
|
|
|
*/
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateStmt:
|
|
|
|
case T_CreateForeignTableStmt:
|
|
|
|
{
|
|
|
|
List *stmts;
|
|
|
|
ListCell *l;
|
|
|
|
|
|
|
|
/* Run parse analysis ... */
|
|
|
|
stmts = transformCreateStmt((CreateStmt *) parsetree,
|
|
|
|
queryString);
|
|
|
|
|
|
|
|
/* ... and do it */
|
|
|
|
foreach(l, stmts)
|
|
|
|
{
|
|
|
|
Node *stmt = (Node *) lfirst(l);
|
|
|
|
|
|
|
|
if (IsA(stmt, CreateStmt))
|
|
|
|
{
|
|
|
|
Datum toast_options;
|
|
|
|
static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
|
|
|
|
|
|
|
|
/* Create the table itself */
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
address = DefineRelation((CreateStmt *) stmt,
|
|
|
|
RELKIND_RELATION,
|
|
|
|
InvalidOid, NULL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerCollectSimpleCommand(address,
|
|
|
|
secondaryObject,
|
|
|
|
stmt);
|
2013-04-28 05:11:28 +02:00
|
|
|
|
|
|
|
/*
|
2014-04-06 17:13:43 +02:00
|
|
|
* Let NewRelationCreateToastTable decide if this
|
2013-04-28 05:11:28 +02:00
|
|
|
* one needs a secondary relation too.
|
|
|
|
*/
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* parse and validate reloptions for the toast
|
|
|
|
* table
|
|
|
|
*/
|
|
|
|
toast_options = transformRelOptions((Datum) 0,
|
|
|
|
((CreateStmt *) stmt)->options,
|
|
|
|
"toast",
|
|
|
|
validnsps,
|
|
|
|
true,
|
|
|
|
false);
|
|
|
|
(void) heap_reloptions(RELKIND_TOASTVALUE,
|
|
|
|
toast_options,
|
|
|
|
true);
|
|
|
|
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
NewRelationCreateToastTable(address.objectId,
|
|
|
|
toast_options);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
else if (IsA(stmt, CreateForeignTableStmt))
|
|
|
|
{
|
|
|
|
/* Create the table itself */
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
address = DefineRelation((CreateStmt *) stmt,
|
|
|
|
RELKIND_FOREIGN_TABLE,
|
|
|
|
InvalidOid, NULL);
|
2013-04-28 05:11:28 +02:00
|
|
|
CreateForeignTable((CreateForeignTableStmt *) stmt,
|
Change many routines to return ObjectAddress rather than OID
The changed routines are mostly those that can be directly called by
ProcessUtilitySlow; the intention is to make the affected object
information more precise, in support for future event trigger changes.
Originally it was envisioned that the OID of the affected object would
be enough, and in most cases that is correct, but upon actually
implementing the event trigger changes it turned out that ObjectAddress
is more widely useful.
Additionally, some command execution routines grew an output argument
that's an object address which provides further info about the executed
command. To wit:
* for ALTER DOMAIN / ADD CONSTRAINT, it corresponds to the address of
the new constraint
* for ALTER OBJECT / SET SCHEMA, it corresponds to the address of the
schema that originally contained the object.
* for ALTER EXTENSION {ADD, DROP} OBJECT, it corresponds to the address
of the object added to or dropped from the extension.
There's no user-visible change in this commit, and no functional change
either.
Discussion: 20150218213255.GC6717@tamriel.snowman.net
Reviewed-By: Stephen Frost, Andres Freund
2015-03-03 18:10:50 +01:00
|
|
|
address.objectId);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerCollectSimpleCommand(address,
|
|
|
|
secondaryObject,
|
|
|
|
stmt);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
|
|
|
* Recurse for anything else. Note the recursive
|
|
|
|
* call will stash the objects so created into our
|
|
|
|
* event trigger context.
|
|
|
|
*/
|
2013-04-28 05:11:28 +02:00
|
|
|
ProcessUtility(stmt,
|
|
|
|
queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
PROCESS_UTILITY_SUBCOMMAND,
|
2013-04-28 05:11:28 +02:00
|
|
|
params,
|
|
|
|
None_Receiver,
|
2013-04-28 06:18:45 +02:00
|
|
|
NULL);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Need CCI between commands */
|
|
|
|
if (lnext(l) != NULL)
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The multiple commands generated here are stashed
|
|
|
|
* individually, so disable collection below.
|
|
|
|
*/
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterTableStmt:
|
|
|
|
{
|
|
|
|
AlterTableStmt *atstmt = (AlterTableStmt *) parsetree;
|
|
|
|
Oid relid;
|
|
|
|
List *stmts;
|
|
|
|
ListCell *l;
|
|
|
|
LOCKMODE lockmode;
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Figure out lock mode, and acquire lock. This also does
|
2013-04-28 05:11:28 +02:00
|
|
|
* basic permissions checks, so that we won't wait for a
|
|
|
|
* lock on (for example) a relation on which we have no
|
|
|
|
* permissions.
|
|
|
|
*/
|
|
|
|
lockmode = AlterTableGetLockLevel(atstmt->cmds);
|
|
|
|
relid = AlterTableLookupRelation(atstmt, lockmode);
|
|
|
|
|
|
|
|
if (OidIsValid(relid))
|
|
|
|
{
|
|
|
|
/* Run parse analysis ... */
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
stmts = transformAlterTableStmt(relid, atstmt,
|
|
|
|
queryString);
|
2013-04-28 05:11:28 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* ... ensure we have an event trigger context ... */
|
|
|
|
EventTriggerAlterTableStart(parsetree);
|
|
|
|
EventTriggerAlterTableRelid(relid);
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
/* ... and do it */
|
|
|
|
foreach(l, stmts)
|
|
|
|
{
|
|
|
|
Node *stmt = (Node *) lfirst(l);
|
|
|
|
|
|
|
|
if (IsA(stmt, AlterTableStmt))
|
|
|
|
{
|
|
|
|
/* Do the table alteration proper */
|
|
|
|
AlterTable(relid, lockmode,
|
|
|
|
(AlterTableStmt *) stmt);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* Recurse for anything else. If we need to
|
|
|
|
* do so, "close" the current complex-command
|
|
|
|
* set, and start a new one at the bottom;
|
|
|
|
* this is needed to ensure the ordering of
|
|
|
|
* queued commands is consistent with the way
|
|
|
|
* they are executed here.
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
*/
|
|
|
|
EventTriggerAlterTableEnd();
|
2013-04-28 05:11:28 +02:00
|
|
|
ProcessUtility(stmt,
|
|
|
|
queryString,
|
2013-04-28 06:18:45 +02:00
|
|
|
PROCESS_UTILITY_SUBCOMMAND,
|
2013-04-28 05:11:28 +02:00
|
|
|
params,
|
|
|
|
None_Receiver,
|
2013-04-28 06:18:45 +02:00
|
|
|
NULL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerAlterTableStart(parsetree);
|
|
|
|
EventTriggerAlterTableRelid(relid);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Need CCI between commands */
|
|
|
|
if (lnext(l) != NULL)
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
|
|
|
|
/* done */
|
|
|
|
EventTriggerAlterTableEnd();
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
ereport(NOTICE,
|
|
|
|
(errmsg("relation \"%s\" does not exist, skipping",
|
|
|
|
atstmt->relation->relname)));
|
|
|
|
}
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
|
|
|
|
/* ALTER TABLE stashes commands internally */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterDomainStmt:
|
|
|
|
{
|
|
|
|
AlterDomainStmt *stmt = (AlterDomainStmt *) parsetree;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some or all of these functions are recursive to cover
|
|
|
|
* inherited things, so permission checks are done there.
|
|
|
|
*/
|
|
|
|
switch (stmt->subtype)
|
|
|
|
{
|
|
|
|
case 'T': /* ALTER DOMAIN DEFAULT */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Recursively alter column default for table and,
|
|
|
|
* if requested, for descendants
|
|
|
|
*/
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainDefault(stmt->typeName,
|
|
|
|
stmt->def);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case 'N': /* ALTER DOMAIN DROP NOT NULL */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainNotNull(stmt->typeName,
|
|
|
|
false);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case 'O': /* ALTER DOMAIN SET NOT NULL */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainNotNull(stmt->typeName,
|
|
|
|
true);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case 'C': /* ADD CONSTRAINT */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainAddConstraint(stmt->typeName,
|
|
|
|
stmt->def,
|
|
|
|
&secondaryObject);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case 'X': /* DROP CONSTRAINT */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainDropConstraint(stmt->typeName,
|
|
|
|
stmt->name,
|
|
|
|
stmt->behavior,
|
|
|
|
stmt->missing_ok);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case 'V': /* VALIDATE CONSTRAINT */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
AlterDomainValidateConstraint(stmt->typeName,
|
|
|
|
stmt->name);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
default: /* oops */
|
|
|
|
elog(ERROR, "unrecognized alter domain type: %d",
|
|
|
|
(int) stmt->subtype);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ************* object creation / destruction **************
|
|
|
|
*/
|
|
|
|
case T_DefineStmt:
|
|
|
|
{
|
|
|
|
DefineStmt *stmt = (DefineStmt *) parsetree;
|
|
|
|
|
|
|
|
switch (stmt->kind)
|
|
|
|
{
|
|
|
|
case OBJECT_AGGREGATE:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
DefineAggregate(stmt->defnames, stmt->args,
|
|
|
|
stmt->oldstyle,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition, queryString);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_OPERATOR:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineOperator(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TYPE:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineType(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSPARSER:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineTSParser(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSDICTIONARY:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineTSDictionary(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSTEMPLATE:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineTSTemplate(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_TSCONFIGURATION:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineTSConfiguration(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition,
|
|
|
|
&secondaryObject);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
case OBJECT_COLLATION:
|
|
|
|
Assert(stmt->args == NIL);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineCollation(stmt->defnames,
|
2015-05-24 03:35:49 +02:00
|
|
|
stmt->definition);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized define stmt type: %d",
|
|
|
|
(int) stmt->kind);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_IndexStmt: /* CREATE INDEX */
|
|
|
|
{
|
|
|
|
IndexStmt *stmt = (IndexStmt *) parsetree;
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
Oid relid;
|
|
|
|
LOCKMODE lockmode;
|
2013-04-28 05:11:28 +02:00
|
|
|
|
|
|
|
if (stmt->concurrent)
|
|
|
|
PreventTransactionChain(isTopLevel,
|
|
|
|
"CREATE INDEX CONCURRENTLY");
|
|
|
|
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
/*
|
|
|
|
* Look up the relation OID just once, right here at the
|
|
|
|
* beginning, so that we don't end up repeating the name
|
|
|
|
* lookup later and latching onto a different relation
|
|
|
|
* partway through. To avoid lock upgrade hazards, it's
|
|
|
|
* important that we take the strongest lock that will
|
|
|
|
* eventually be needed here, so the lockmode calculation
|
|
|
|
* needs to match what DefineIndex() does.
|
|
|
|
*/
|
|
|
|
lockmode = stmt->concurrent ? ShareUpdateExclusiveLock
|
|
|
|
: ShareLock;
|
|
|
|
relid =
|
|
|
|
RangeVarGetRelidExtended(stmt->relation, lockmode,
|
|
|
|
false, false,
|
|
|
|
RangeVarCallbackOwnsRelation,
|
|
|
|
NULL);
|
2013-04-28 05:11:28 +02:00
|
|
|
|
|
|
|
/* Run parse analysis ... */
|
Avoid repeated name lookups during table and index DDL.
If the name lookups come to different conclusions due to concurrent
activity, we might perform some parts of the DDL on a different table
than other parts. At least in the case of CREATE INDEX, this can be
used to cause the permissions checks to be performed against a
different table than the index creation, allowing for a privilege
escalation attack.
This changes the calling convention for DefineIndex, CreateTrigger,
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible
(in 9.2 and newer), and AlterTable (in 9.1 and older). In addition,
CheckRelationOwnership is removed in 9.2 and newer and the calling
convention is changed in older branches. A field has also been added
to the Constraint node (FkConstraint in 8.4). Third-party code calling
these functions or using the Constraint node will require updating.
Report by Andres Freund. Patch by Robert Haas and Andres Freund,
reviewed by Tom Lane.
Security: CVE-2014-0062
2014-02-17 15:33:31 +01:00
|
|
|
stmt = transformIndexStmt(relid, stmt, queryString);
|
2013-04-28 05:11:28 +02:00
|
|
|
|
|
|
|
/* ... and do it */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerAlterTableStart(parsetree);
|
|
|
|
address =
|
2015-05-24 03:35:49 +02:00
|
|
|
DefineIndex(relid, /* OID of heap relation */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
stmt,
|
2015-05-24 03:35:49 +02:00
|
|
|
InvalidOid, /* no predefined OID */
|
|
|
|
false, /* is_alter_table */
|
|
|
|
true, /* check_rights */
|
|
|
|
false, /* skip_build */
|
|
|
|
false); /* quiet */
|
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
2015-05-24 03:35:49 +02:00
|
|
|
* Add the CREATE INDEX node itself to stash right away;
|
|
|
|
* if there were any commands stashed in the ALTER TABLE
|
|
|
|
* code, we need them to appear after this one.
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
*/
|
|
|
|
EventTriggerCollectSimpleCommand(address, secondaryObject,
|
|
|
|
parsetree);
|
|
|
|
commandCollected = true;
|
|
|
|
EventTriggerAlterTableEnd();
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateExtensionStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateExtension((CreateExtensionStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterExtensionStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecAlterExtensionStmt((AlterExtensionStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterExtensionContentsStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecAlterExtensionContentsStmt((AlterExtensionContentsStmt *) parsetree,
|
2015-05-24 03:35:49 +02:00
|
|
|
&secondaryObject);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateFdwStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateForeignDataWrapper((CreateFdwStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterFdwStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterForeignDataWrapper((AlterFdwStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateForeignServerStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateForeignServer((CreateForeignServerStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterForeignServerStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterForeignServer((AlterForeignServerStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateUserMappingStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateUserMapping((CreateUserMappingStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterUserMappingStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterUserMapping((AlterUserMappingStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropUserMappingStmt:
|
|
|
|
RemoveUserMapping((DropUserMappingStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* no commands stashed for DROP */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
case T_ImportForeignSchemaStmt:
|
|
|
|
ImportForeignSchema((ImportForeignSchemaStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* commands are stashed inside ImportForeignSchema */
|
|
|
|
commandCollected = true;
|
2014-07-10 21:01:31 +02:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_CompositeTypeStmt: /* CREATE TYPE (composite) */
|
|
|
|
{
|
|
|
|
CompositeTypeStmt *stmt = (CompositeTypeStmt *) parsetree;
|
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineCompositeType(stmt->typevar,
|
|
|
|
stmt->coldeflist);
|
2013-04-28 05:11:28 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateEnumStmt: /* CREATE TYPE AS ENUM */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineEnum((CreateEnumStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateRangeStmt: /* CREATE TYPE AS RANGE */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineRange((CreateRangeStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterEnumStmt: /* ALTER TYPE (enum) */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterEnum((AlterEnumStmt *) parsetree, isTopLevel);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ViewStmt: /* CREATE VIEW */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerAlterTableStart(parsetree);
|
|
|
|
address = DefineView((ViewStmt *) parsetree, queryString);
|
|
|
|
EventTriggerCollectSimpleCommand(address, secondaryObject,
|
|
|
|
parsetree);
|
|
|
|
/* stashed internally */
|
|
|
|
commandCollected = true;
|
|
|
|
EventTriggerAlterTableEnd();
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateFunctionStmt: /* CREATE FUNCTION */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateFunction((CreateFunctionStmt *) parsetree, queryString);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterFunctionStmt: /* ALTER FUNCTION */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterFunction((AlterFunctionStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RuleStmt: /* CREATE RULE */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineRule((RuleStmt *) parsetree, queryString);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateSeqStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineSequence((CreateSeqStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterSeqStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterSequence((AlterSeqStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateTableAsStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecCreateTableAs((CreateTableAsStmt *) parsetree,
|
2015-05-24 03:35:49 +02:00
|
|
|
queryString, params, completionTag);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RefreshMatViewStmt:
|
2015-05-24 03:35:49 +02:00
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
|
|
|
* REFRSH CONCURRENTLY executes some DDL commands internally.
|
|
|
|
* Inhibit DDL command collection here to avoid those commands
|
|
|
|
* from showing up in the deparsed command queue. The refresh
|
|
|
|
* command itself is queued, which is enough.
|
|
|
|
*/
|
|
|
|
EventTriggerInhibitCommandCollection();
|
|
|
|
PG_TRY();
|
|
|
|
{
|
|
|
|
address = ExecRefreshMatView((RefreshMatViewStmt *) parsetree,
|
2015-05-24 03:35:49 +02:00
|
|
|
queryString, params, completionTag);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
}
|
|
|
|
PG_CATCH();
|
|
|
|
{
|
|
|
|
EventTriggerUndoInhibitCommandCollection();
|
|
|
|
PG_RE_THROW();
|
|
|
|
}
|
|
|
|
PG_END_TRY();
|
|
|
|
EventTriggerUndoInhibitCommandCollection();
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateTrigStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateTrigger((CreateTrigStmt *) parsetree,
|
2015-05-24 03:35:49 +02:00
|
|
|
queryString, InvalidOid, InvalidOid,
|
|
|
|
InvalidOid, InvalidOid, false);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreatePLangStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateProceduralLanguage((CreatePLangStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateDomainStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineDomain((CreateDomainStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateConversionStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateConversionCommand((CreateConversionStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateCastStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreateCast((CreateCastStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateOpClassStmt:
|
|
|
|
DefineOpClass((CreateOpClassStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* command is stashed in DefineOpClass */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateOpFamilyStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = DefineOpFamily((CreateOpFamilyStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
case T_CreateTransformStmt:
|
2015-06-26 23:17:54 +02:00
|
|
|
address = CreateTransform((CreateTransformStmt *) parsetree);
|
2015-04-26 16:33:14 +02:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_AlterOpFamilyStmt:
|
|
|
|
AlterOpFamily((AlterOpFamilyStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* commands are stashed in AlterOpFamily */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterTSDictionaryStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterTSDictionary((AlterTSDictionaryStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterTSConfigurationStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterTSConfiguration((AlterTSConfigurationStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
2014-09-09 16:52:10 +02:00
|
|
|
case T_AlterTableMoveAllStmt:
|
|
|
|
AlterTableMoveAll((AlterTableMoveAllStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* commands are stashed in AlterTableMoveAll */
|
|
|
|
commandCollected = true;
|
2014-09-09 16:52:10 +02:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_DropStmt:
|
|
|
|
ExecDropStmt((DropStmt *) parsetree, isTopLevel);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* no commands stashed for DROP */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RenameStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecRenameStmt((RenameStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterObjectSchemaStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address =
|
|
|
|
ExecAlterObjectSchemaStmt((AlterObjectSchemaStmt *) parsetree,
|
|
|
|
&secondaryObject);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterOwnerStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecAlterOwnerStmt((AlterOwnerStmt *) parsetree);
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
2015-07-14 17:17:55 +02:00
|
|
|
case T_AlterOperatorStmt:
|
|
|
|
address = AlterOperator((AlterOperatorStmt *) parsetree);
|
|
|
|
break;
|
|
|
|
|
2015-02-23 18:22:42 +01:00
|
|
|
case T_CommentStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CommentObject((CommentStmt *) parsetree);
|
2015-02-23 18:22:42 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_GrantStmt:
|
|
|
|
ExecuteGrantStmt((GrantStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* commands are stashed in ExecGrantStmt_oids */
|
|
|
|
commandCollected = true;
|
2015-02-23 18:22:42 +01:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
case T_DropOwnedStmt:
|
|
|
|
DropOwnedObjects((DropOwnedStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/* no commands stashed for DROP */
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterDefaultPrivilegesStmt:
|
|
|
|
ExecAlterDefaultPrivilegesStmt((AlterDefaultPrivilegesStmt *) parsetree);
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
EventTriggerCollectAlterDefPrivs((AlterDefaultPrivilegesStmt *) parsetree);
|
|
|
|
commandCollected = true;
|
2013-04-28 05:11:28 +02:00
|
|
|
break;
|
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case T_CreatePolicyStmt: /* CREATE POLICY */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = CreatePolicy((CreatePolicyStmt *) parsetree);
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterPolicyStmt: /* ALTER POLICY */
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = AlterPolicy((AlterPolicyStmt *) parsetree);
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
break;
|
|
|
|
|
2015-02-23 18:22:42 +01:00
|
|
|
case T_SecLabelStmt:
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
address = ExecSecLabelStmt((SecLabelStmt *) parsetree);
|
2015-02-23 18:22:42 +01:00
|
|
|
break;
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
default:
|
|
|
|
elog(ERROR, "unrecognized node type: %d",
|
|
|
|
(int) nodeTag(parsetree));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Allow on-the-fly capture of DDL event details
This feature lets user code inspect and take action on DDL events.
Whenever a ddl_command_end event trigger is installed, DDL actions
executed are saved to a list which can be inspected during execution of
a function attached to ddl_command_end.
The set-returning function pg_event_trigger_ddl_commands can be used to
list actions so captured; it returns data about the type of command
executed, as well as the affected object. This is sufficient for many
uses of this feature. For the cases where it is not, we also provide a
"command" column of a new pseudo-type pg_ddl_command, which is a
pointer to a C structure that can be accessed by C code. The struct
contains all the info necessary to completely inspect and even
reconstruct the executed command.
There is no actual deparse code here; that's expected to come later.
What we have is enough infrastructure that the deparsing can be done in
an external extension. The intention is that we will add some deparsing
code in a later release, as an in-core extension.
A new test module is included. It's probably insufficient as is, but it
should be sufficient as a starting point for a more complete and
future-proof approach.
Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick,
Abhijit Menon-Sen.
Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier,
Craig Ringer, David Steele.
Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost,
Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule.
Based on original work by Dimitri Fontaine, though I didn't use his
code.
Discussion:
https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr
https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org
https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
|
|
|
/*
|
|
|
|
* Remember the object so that ddl_command_end event triggers have
|
|
|
|
* access to it.
|
|
|
|
*/
|
|
|
|
if (!commandCollected)
|
|
|
|
EventTriggerCollectSimpleCommand(address, secondaryObject,
|
|
|
|
parsetree);
|
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
if (isCompleteQuery)
|
|
|
|
{
|
|
|
|
EventTriggerSQLDrop(parsetree);
|
|
|
|
EventTriggerDDLCommandEnd(parsetree);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PG_CATCH();
|
|
|
|
{
|
|
|
|
if (needCleanup)
|
|
|
|
EventTriggerEndCompleteQuery();
|
|
|
|
PG_RE_THROW();
|
|
|
|
}
|
|
|
|
PG_END_TRY();
|
Add sql_drop event for event triggers
This event takes place just before ddl_command_end, and is fired if and
only if at least one object has been dropped by the command. (For
instance, DROP TABLE IF EXISTS of a table that does not in fact exist
will not lead to such a trigger firing). Commands that drop multiple
objects (such as DROP SCHEMA or DROP OWNED BY) will cause a single event
to fire. Some firings might be surprising, such as
ALTER TABLE DROP COLUMN.
The trigger is fired after the drop has taken place, because that has
been deemed the safest design, to avoid exposing possibly-inconsistent
internal state (system catalogs as well as current transaction) to the
user function code. This means that careful tracking of object
identification is required during the object removal phase.
Like other currently existing events, there is support for tag
filtering.
To support the new event, add a new pg_event_trigger_dropped_objects()
set-returning function, which returns a set of rows comprising the
objects affected by the command. This is to be used within the user
function code, and is mostly modelled after the recently introduced
pg_identify_object() function.
Catalog version bumped due to the new function.
Dimitri Fontaine and Álvaro Herrera
Review by Robert Haas, Tom Lane
2013-03-27 20:02:10 +01:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
if (needCleanup)
|
|
|
|
EventTriggerEndCompleteQuery();
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2003-05-02 22:54:36 +02:00
|
|
|
|
2013-04-28 05:11:28 +02:00
|
|
|
/*
|
|
|
|
* Dispatch function for DropStmt
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ExecDropStmt(DropStmt *stmt, bool isTopLevel)
|
|
|
|
{
|
|
|
|
switch (stmt->removeType)
|
|
|
|
{
|
|
|
|
case OBJECT_INDEX:
|
|
|
|
if (stmt->concurrent)
|
|
|
|
PreventTransactionChain(isTopLevel,
|
|
|
|
"DROP INDEX CONCURRENTLY");
|
|
|
|
/* fall through */
|
|
|
|
|
|
|
|
case OBJECT_TABLE:
|
|
|
|
case OBJECT_SEQUENCE:
|
|
|
|
case OBJECT_VIEW:
|
|
|
|
case OBJECT_MATVIEW:
|
|
|
|
case OBJECT_FOREIGN_TABLE:
|
|
|
|
RemoveRelations(stmt);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
RemoveObjects(stmt);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2003-05-06 22:26:28 +02:00
|
|
|
/*
|
|
|
|
* UtilityReturnsTuples
|
|
|
|
* Return "true" if this utility statement will send output to the
|
|
|
|
* destination.
|
|
|
|
*
|
|
|
|
* Generally, there should be a case here for each case in ProcessUtility
|
|
|
|
* where "dest" is passed on.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
UtilityReturnsTuples(Node *parsetree)
|
|
|
|
{
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
|
|
|
case T_FetchStmt:
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
FetchStmt *stmt = (FetchStmt *) parsetree;
|
|
|
|
Portal portal;
|
2003-05-06 22:26:28 +02:00
|
|
|
|
|
|
|
if (stmt->ismove)
|
|
|
|
return false;
|
|
|
|
portal = GetPortalByName(stmt->portalname);
|
|
|
|
if (!PortalIsValid(portal))
|
2003-08-04 02:43:34 +02:00
|
|
|
return false; /* not our business to raise error */
|
2003-05-06 22:26:28 +02:00
|
|
|
return portal->tupDesc ? true : false;
|
|
|
|
}
|
|
|
|
|
|
|
|
case T_ExecuteStmt:
|
|
|
|
{
|
|
|
|
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
|
|
|
|
PreparedStatement *entry;
|
|
|
|
|
|
|
|
entry = FetchPreparedStatement(stmt->name, false);
|
|
|
|
if (!entry)
|
2003-08-04 02:43:34 +02:00
|
|
|
return false; /* not our business to raise error */
|
2007-03-13 01:33:44 +01:00
|
|
|
if (entry->plansource->resultDesc)
|
|
|
|
return true;
|
2003-05-06 22:26:28 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
case T_ExplainStmt:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case T_VariableShowStmt:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* UtilityTupleDescriptor
|
|
|
|
* Fetch the actual output tuple descriptor for a utility statement
|
|
|
|
* for which UtilityReturnsTuples() previously returned "true".
|
|
|
|
*
|
|
|
|
* The returned descriptor is created in (or copied into) the current memory
|
|
|
|
* context.
|
|
|
|
*/
|
|
|
|
TupleDesc
|
|
|
|
UtilityTupleDescriptor(Node *parsetree)
|
|
|
|
{
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
|
|
|
case T_FetchStmt:
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
FetchStmt *stmt = (FetchStmt *) parsetree;
|
|
|
|
Portal portal;
|
2003-05-06 22:26:28 +02:00
|
|
|
|
|
|
|
if (stmt->ismove)
|
|
|
|
return NULL;
|
|
|
|
portal = GetPortalByName(stmt->portalname);
|
|
|
|
if (!PortalIsValid(portal))
|
2003-08-04 02:43:34 +02:00
|
|
|
return NULL; /* not our business to raise error */
|
2003-05-06 22:26:28 +02:00
|
|
|
return CreateTupleDescCopy(portal->tupDesc);
|
|
|
|
}
|
|
|
|
|
|
|
|
case T_ExecuteStmt:
|
|
|
|
{
|
|
|
|
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
|
|
|
|
PreparedStatement *entry;
|
|
|
|
|
|
|
|
entry = FetchPreparedStatement(stmt->name, false);
|
|
|
|
if (!entry)
|
2003-08-04 02:43:34 +02:00
|
|
|
return NULL; /* not our business to raise error */
|
2003-05-06 23:51:42 +02:00
|
|
|
return FetchPreparedStatementResultDesc(entry);
|
2003-05-06 22:26:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
case T_ExplainStmt:
|
|
|
|
return ExplainResultDesc((ExplainStmt *) parsetree);
|
|
|
|
|
|
|
|
case T_VariableShowStmt:
|
|
|
|
{
|
|
|
|
VariableShowStmt *n = (VariableShowStmt *) parsetree;
|
|
|
|
|
|
|
|
return GetPGVariableResultDesc(n->name);
|
|
|
|
}
|
|
|
|
|
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
|
2006-08-12 22:05:56 +02:00
|
|
|
/*
|
|
|
|
* QueryReturnsTuples
|
|
|
|
* Return "true" if this Query will send output to the destination.
|
|
|
|
*/
|
2007-02-20 18:32:18 +01:00
|
|
|
#ifdef NOT_USED
|
2006-08-12 22:05:56 +02:00
|
|
|
bool
|
|
|
|
QueryReturnsTuples(Query *parsetree)
|
|
|
|
{
|
|
|
|
switch (parsetree->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
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
|
|
|
/* returns tuples ... unless it's DECLARE CURSOR */
|
|
|
|
if (parsetree->utilityStmt == NULL)
|
2006-08-12 22:05:56 +02:00
|
|
|
return true;
|
|
|
|
break;
|
|
|
|
case CMD_INSERT:
|
|
|
|
case CMD_UPDATE:
|
|
|
|
case CMD_DELETE:
|
|
|
|
/* the forms with RETURNING return tuples */
|
|
|
|
if (parsetree->returningList)
|
|
|
|
return true;
|
|
|
|
break;
|
|
|
|
case CMD_UTILITY:
|
|
|
|
return UtilityReturnsTuples(parsetree->utilityStmt);
|
|
|
|
case CMD_UNKNOWN:
|
|
|
|
case CMD_NOTHING:
|
|
|
|
/* probably shouldn't get here */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false; /* default */
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
#endif
|
2006-08-12 22:05:56 +02: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
|
|
|
/*
|
|
|
|
* UtilityContainsQuery
|
|
|
|
* Return the contained Query, or NULL if there is none
|
|
|
|
*
|
2012-06-28 05:18:30 +02:00
|
|
|
* Certain utility statements, such as EXPLAIN, contain a plannable 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
|
|
|
* This function encapsulates knowledge of exactly which ones do.
|
|
|
|
* We assume it is invoked only on already-parse-analyzed statements
|
|
|
|
* (else the contained parsetree isn't a Query yet).
|
2012-06-28 05:18:30 +02:00
|
|
|
*
|
2013-03-04 01:23:31 +01:00
|
|
|
* In some cases (currently, only EXPLAIN of CREATE TABLE AS/SELECT INTO and
|
|
|
|
* CREATE MATERIALIZED VIEW), potentially Query-containing utility statements
|
|
|
|
* can be nested. This function will drill down to a non-utility Query, or
|
|
|
|
* return NULL if none.
|
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
|
|
|
*/
|
|
|
|
Query *
|
|
|
|
UtilityContainsQuery(Node *parsetree)
|
|
|
|
{
|
2012-06-28 05:18:30 +02:00
|
|
|
Query *qry;
|
|
|
|
|
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
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
|
|
|
case T_ExplainStmt:
|
2012-06-28 05:18:30 +02:00
|
|
|
qry = (Query *) ((ExplainStmt *) parsetree)->query;
|
|
|
|
Assert(IsA(qry, Query));
|
|
|
|
if (qry->commandType == CMD_UTILITY)
|
|
|
|
return UtilityContainsQuery(qry->utilityStmt);
|
|
|
|
return qry;
|
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
|
|
|
|
|
|
|
case T_CreateTableAsStmt:
|
2012-06-28 05:18:30 +02:00
|
|
|
qry = (Query *) ((CreateTableAsStmt *) parsetree)->query;
|
2012-10-20 00:33:45 +02:00
|
|
|
Assert(IsA(qry, Query));
|
|
|
|
if (qry->commandType == CMD_UTILITY)
|
|
|
|
return UtilityContainsQuery(qry->utilityStmt);
|
|
|
|
return qry;
|
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
|
|
|
|
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-02-09 17:55:32 +01:00
|
|
|
/*
|
|
|
|
* AlterObjectTypeCommandTag
|
|
|
|
* helper function for CreateCommandTag
|
|
|
|
*
|
|
|
|
* This covers most cases where ALTER is used with an ObjectType enum.
|
|
|
|
*/
|
|
|
|
static const char *
|
|
|
|
AlterObjectTypeCommandTag(ObjectType objtype)
|
|
|
|
{
|
|
|
|
const char *tag;
|
|
|
|
|
|
|
|
switch (objtype)
|
|
|
|
{
|
|
|
|
case OBJECT_AGGREGATE:
|
|
|
|
tag = "ALTER AGGREGATE";
|
|
|
|
break;
|
|
|
|
case OBJECT_ATTRIBUTE:
|
|
|
|
tag = "ALTER TYPE";
|
|
|
|
break;
|
|
|
|
case OBJECT_CAST:
|
|
|
|
tag = "ALTER CAST";
|
|
|
|
break;
|
2011-02-12 14:54:13 +01:00
|
|
|
case OBJECT_COLLATION:
|
|
|
|
tag = "ALTER COLLATION";
|
|
|
|
break;
|
2011-02-09 17:55:32 +01:00
|
|
|
case OBJECT_COLUMN:
|
|
|
|
tag = "ALTER TABLE";
|
|
|
|
break;
|
|
|
|
case OBJECT_CONVERSION:
|
|
|
|
tag = "ALTER CONVERSION";
|
|
|
|
break;
|
|
|
|
case OBJECT_DATABASE:
|
|
|
|
tag = "ALTER DATABASE";
|
|
|
|
break;
|
|
|
|
case OBJECT_DOMAIN:
|
2014-12-23 13:06:44 +01:00
|
|
|
case OBJECT_DOMCONSTRAINT:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = "ALTER DOMAIN";
|
|
|
|
break;
|
|
|
|
case OBJECT_EXTENSION:
|
|
|
|
tag = "ALTER EXTENSION";
|
|
|
|
break;
|
|
|
|
case OBJECT_FDW:
|
|
|
|
tag = "ALTER FOREIGN DATA WRAPPER";
|
|
|
|
break;
|
|
|
|
case OBJECT_FOREIGN_SERVER:
|
|
|
|
tag = "ALTER SERVER";
|
|
|
|
break;
|
|
|
|
case OBJECT_FOREIGN_TABLE:
|
|
|
|
tag = "ALTER FOREIGN TABLE";
|
|
|
|
break;
|
|
|
|
case OBJECT_FUNCTION:
|
|
|
|
tag = "ALTER FUNCTION";
|
|
|
|
break;
|
|
|
|
case OBJECT_INDEX:
|
|
|
|
tag = "ALTER INDEX";
|
|
|
|
break;
|
|
|
|
case OBJECT_LANGUAGE:
|
|
|
|
tag = "ALTER LANGUAGE";
|
|
|
|
break;
|
|
|
|
case OBJECT_LARGEOBJECT:
|
|
|
|
tag = "ALTER LARGE OBJECT";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPCLASS:
|
|
|
|
tag = "ALTER OPERATOR CLASS";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPERATOR:
|
|
|
|
tag = "ALTER OPERATOR";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPFAMILY:
|
|
|
|
tag = "ALTER OPERATOR FAMILY";
|
|
|
|
break;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case OBJECT_POLICY:
|
|
|
|
tag = "ALTER POLICY";
|
|
|
|
break;
|
2011-02-09 17:55:32 +01:00
|
|
|
case OBJECT_ROLE:
|
|
|
|
tag = "ALTER ROLE";
|
|
|
|
break;
|
|
|
|
case OBJECT_RULE:
|
|
|
|
tag = "ALTER RULE";
|
|
|
|
break;
|
|
|
|
case OBJECT_SCHEMA:
|
|
|
|
tag = "ALTER SCHEMA";
|
|
|
|
break;
|
|
|
|
case OBJECT_SEQUENCE:
|
|
|
|
tag = "ALTER SEQUENCE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TABLE:
|
2014-12-23 13:06:44 +01:00
|
|
|
case OBJECT_TABCONSTRAINT:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = "ALTER TABLE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TABLESPACE:
|
|
|
|
tag = "ALTER TABLESPACE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TRIGGER:
|
|
|
|
tag = "ALTER TRIGGER";
|
|
|
|
break;
|
2012-07-18 16:16:16 +02:00
|
|
|
case OBJECT_EVENT_TRIGGER:
|
|
|
|
tag = "ALTER EVENT TRIGGER";
|
|
|
|
break;
|
2011-02-09 17:55:32 +01:00
|
|
|
case OBJECT_TSCONFIGURATION:
|
|
|
|
tag = "ALTER TEXT SEARCH CONFIGURATION";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSDICTIONARY:
|
|
|
|
tag = "ALTER TEXT SEARCH DICTIONARY";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSPARSER:
|
|
|
|
tag = "ALTER TEXT SEARCH PARSER";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSTEMPLATE:
|
|
|
|
tag = "ALTER TEXT SEARCH TEMPLATE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TYPE:
|
|
|
|
tag = "ALTER TYPE";
|
|
|
|
break;
|
|
|
|
case OBJECT_VIEW:
|
|
|
|
tag = "ALTER VIEW";
|
|
|
|
break;
|
2013-03-04 01:23:31 +01:00
|
|
|
case OBJECT_MATVIEW:
|
|
|
|
tag = "ALTER MATERIALIZED VIEW";
|
|
|
|
break;
|
2011-02-09 17:55:32 +01:00
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return tag;
|
|
|
|
}
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
/*
|
|
|
|
* CreateCommandTag
|
2007-02-20 18:32:18 +01:00
|
|
|
* utility to get a string representation of the command operation,
|
|
|
|
* given either a raw (un-analyzed) parsetree or a planned query.
|
2003-05-02 22:54:36 +02:00
|
|
|
*
|
2007-02-20 18:32:18 +01:00
|
|
|
* This must handle all command types, but since the vast majority
|
2003-05-02 22:54:36 +02:00
|
|
|
* of 'em are utility commands, it seems sensible to keep it here.
|
|
|
|
*
|
|
|
|
* NB: all result strings must be shorter than COMPLETION_TAG_BUFSIZE.
|
|
|
|
* Also, the result must point at a true constant (permanent storage).
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
CreateCommandTag(Node *parsetree)
|
|
|
|
{
|
|
|
|
const char *tag;
|
|
|
|
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
/* raw plannable queries */
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_InsertStmt:
|
|
|
|
tag = "INSERT";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeleteStmt:
|
|
|
|
tag = "DELETE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_UpdateStmt:
|
|
|
|
tag = "UPDATE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_SelectStmt:
|
|
|
|
tag = "SELECT";
|
|
|
|
break;
|
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* utility statements --- same whether raw or cooked */
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_TransactionStmt:
|
|
|
|
{
|
|
|
|
TransactionStmt *stmt = (TransactionStmt *) parsetree;
|
|
|
|
|
|
|
|
switch (stmt->kind)
|
|
|
|
{
|
|
|
|
case TRANS_STMT_BEGIN:
|
|
|
|
tag = "BEGIN";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_START:
|
|
|
|
tag = "START TRANSACTION";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_COMMIT:
|
|
|
|
tag = "COMMIT";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_ROLLBACK:
|
2004-07-27 07:11:48 +02:00
|
|
|
case TRANS_STMT_ROLLBACK_TO:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "ROLLBACK";
|
|
|
|
break;
|
|
|
|
|
2004-07-27 07:11:48 +02:00
|
|
|
case TRANS_STMT_SAVEPOINT:
|
|
|
|
tag = "SAVEPOINT";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_RELEASE:
|
|
|
|
tag = "RELEASE";
|
|
|
|
break;
|
|
|
|
|
2005-06-18 00:32:51 +02:00
|
|
|
case TRANS_STMT_PREPARE:
|
|
|
|
tag = "PREPARE TRANSACTION";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_COMMIT_PREPARED:
|
|
|
|
tag = "COMMIT PREPARED";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TRANS_STMT_ROLLBACK_PREPARED:
|
|
|
|
tag = "ROLLBACK PREPARED";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeclareCursorStmt:
|
|
|
|
tag = "DECLARE CURSOR";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ClosePortalStmt:
|
2007-04-12 08:53:49 +02:00
|
|
|
{
|
|
|
|
ClosePortalStmt *stmt = (ClosePortalStmt *) parsetree;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-04-12 08:53:49 +02:00
|
|
|
if (stmt->portalname == NULL)
|
|
|
|
tag = "CLOSE CURSOR ALL";
|
|
|
|
else
|
|
|
|
tag = "CLOSE CURSOR";
|
|
|
|
}
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_FetchStmt:
|
|
|
|
{
|
|
|
|
FetchStmt *stmt = (FetchStmt *) parsetree;
|
|
|
|
|
|
|
|
tag = (stmt->ismove) ? "MOVE" : "FETCH";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateDomainStmt:
|
|
|
|
tag = "CREATE DOMAIN";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateSchemaStmt:
|
|
|
|
tag = "CREATE SCHEMA";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateStmt:
|
|
|
|
tag = "CREATE TABLE";
|
|
|
|
break;
|
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
case T_CreateTableSpaceStmt:
|
|
|
|
tag = "CREATE TABLESPACE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropTableSpaceStmt:
|
|
|
|
tag = "DROP TABLESPACE";
|
|
|
|
break;
|
|
|
|
|
2010-01-05 22:54:00 +01:00
|
|
|
case T_AlterTableSpaceOptionsStmt:
|
|
|
|
tag = "ALTER TABLESPACE";
|
|
|
|
break;
|
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
case T_CreateExtensionStmt:
|
|
|
|
tag = "CREATE EXTENSION";
|
|
|
|
break;
|
|
|
|
|
2011-02-12 03:25:20 +01:00
|
|
|
case T_AlterExtensionStmt:
|
|
|
|
tag = "ALTER EXTENSION";
|
|
|
|
break;
|
|
|
|
|
2011-02-10 23:36:44 +01:00
|
|
|
case T_AlterExtensionContentsStmt:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = "ALTER EXTENSION";
|
|
|
|
break;
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
case T_CreateFdwStmt:
|
|
|
|
tag = "CREATE FOREIGN DATA WRAPPER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterFdwStmt:
|
|
|
|
tag = "ALTER FOREIGN DATA WRAPPER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateForeignServerStmt:
|
|
|
|
tag = "CREATE SERVER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterForeignServerStmt:
|
|
|
|
tag = "ALTER SERVER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateUserMappingStmt:
|
|
|
|
tag = "CREATE USER MAPPING";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterUserMappingStmt:
|
|
|
|
tag = "ALTER USER MAPPING";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropUserMappingStmt:
|
|
|
|
tag = "DROP USER MAPPING";
|
|
|
|
break;
|
|
|
|
|
2011-01-02 05:48:11 +01:00
|
|
|
case T_CreateForeignTableStmt:
|
|
|
|
tag = "CREATE FOREIGN TABLE";
|
|
|
|
break;
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
case T_ImportForeignSchemaStmt:
|
|
|
|
tag = "IMPORT FOREIGN SCHEMA";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_DropStmt:
|
|
|
|
switch (((DropStmt *) parsetree)->removeType)
|
|
|
|
{
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_TABLE:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP TABLE";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_SEQUENCE:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP SEQUENCE";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_VIEW:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP VIEW";
|
|
|
|
break;
|
2013-03-04 01:23:31 +01:00
|
|
|
case OBJECT_MATVIEW:
|
|
|
|
tag = "DROP MATERIALIZED VIEW";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_INDEX:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP INDEX";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_TYPE:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP TYPE";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_DOMAIN:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP DOMAIN";
|
|
|
|
break;
|
2011-02-12 14:54:13 +01:00
|
|
|
case OBJECT_COLLATION:
|
|
|
|
tag = "DROP COLLATION";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_CONVERSION:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP CONVERSION";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_SCHEMA:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "DROP SCHEMA";
|
|
|
|
break;
|
2007-08-21 03:11:32 +02:00
|
|
|
case OBJECT_TSPARSER:
|
|
|
|
tag = "DROP TEXT SEARCH PARSER";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSDICTIONARY:
|
|
|
|
tag = "DROP TEXT SEARCH DICTIONARY";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSTEMPLATE:
|
|
|
|
tag = "DROP TEXT SEARCH TEMPLATE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSCONFIGURATION:
|
|
|
|
tag = "DROP TEXT SEARCH CONFIGURATION";
|
|
|
|
break;
|
2011-01-02 05:48:11 +01:00
|
|
|
case OBJECT_FOREIGN_TABLE:
|
|
|
|
tag = "DROP FOREIGN TABLE";
|
|
|
|
break;
|
2011-02-08 22:08:41 +01:00
|
|
|
case OBJECT_EXTENSION:
|
|
|
|
tag = "DROP EXTENSION";
|
|
|
|
break;
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_FUNCTION:
|
|
|
|
tag = "DROP FUNCTION";
|
|
|
|
break;
|
|
|
|
case OBJECT_AGGREGATE:
|
|
|
|
tag = "DROP AGGREGATE";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPERATOR:
|
|
|
|
tag = "DROP OPERATOR";
|
|
|
|
break;
|
|
|
|
case OBJECT_LANGUAGE:
|
|
|
|
tag = "DROP LANGUAGE";
|
|
|
|
break;
|
|
|
|
case OBJECT_CAST:
|
|
|
|
tag = "DROP CAST";
|
|
|
|
break;
|
|
|
|
case OBJECT_TRIGGER:
|
|
|
|
tag = "DROP TRIGGER";
|
|
|
|
break;
|
2012-07-18 16:16:16 +02:00
|
|
|
case OBJECT_EVENT_TRIGGER:
|
|
|
|
tag = "DROP EVENT TRIGGER";
|
|
|
|
break;
|
2011-11-18 03:31:29 +01:00
|
|
|
case OBJECT_RULE:
|
|
|
|
tag = "DROP RULE";
|
|
|
|
break;
|
|
|
|
case OBJECT_FDW:
|
|
|
|
tag = "DROP FOREIGN DATA WRAPPER";
|
|
|
|
break;
|
|
|
|
case OBJECT_FOREIGN_SERVER:
|
|
|
|
tag = "DROP SERVER";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPCLASS:
|
|
|
|
tag = "DROP OPERATOR CLASS";
|
|
|
|
break;
|
|
|
|
case OBJECT_OPFAMILY:
|
|
|
|
tag = "DROP OPERATOR FAMILY";
|
|
|
|
break;
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case OBJECT_POLICY:
|
|
|
|
tag = "DROP POLICY";
|
|
|
|
break;
|
2015-04-26 16:33:14 +02:00
|
|
|
case OBJECT_TRANSFORM:
|
|
|
|
tag = "DROP TRANSFORM";
|
|
|
|
break;
|
2003-05-02 22:54:36 +02:00
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_TruncateStmt:
|
|
|
|
tag = "TRUNCATE TABLE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CommentStmt:
|
|
|
|
tag = "COMMENT";
|
|
|
|
break;
|
|
|
|
|
2010-09-28 02:55:27 +02:00
|
|
|
case T_SecLabelStmt:
|
|
|
|
tag = "SECURITY LABEL";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_CopyStmt:
|
|
|
|
tag = "COPY";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RenameStmt:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = AlterObjectTypeCommandTag(((RenameStmt *) parsetree)->renameType);
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2005-08-01 06:03:59 +02:00
|
|
|
case T_AlterObjectSchemaStmt:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = AlterObjectTypeCommandTag(((AlterObjectSchemaStmt *) parsetree)->objectType);
|
2005-08-01 06:03:59 +02:00
|
|
|
break;
|
|
|
|
|
2004-06-25 23:55:59 +02:00
|
|
|
case T_AlterOwnerStmt:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = AlterObjectTypeCommandTag(((AlterOwnerStmt *) parsetree)->objectType);
|
2004-06-25 23:55:59 +02:00
|
|
|
break;
|
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
case T_AlterTableMoveAllStmt:
|
|
|
|
tag = AlterObjectTypeCommandTag(((AlterTableMoveAllStmt *) parsetree)->objtype);
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_AlterTableStmt:
|
2011-02-09 17:55:32 +01:00
|
|
|
tag = AlterObjectTypeCommandTag(((AlterTableStmt *) parsetree)->relkind);
|
2004-08-20 06:29:33 +02:00
|
|
|
break;
|
2005-03-14 01:19:37 +01:00
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_AlterDomainStmt:
|
|
|
|
tag = "ALTER DOMAIN";
|
|
|
|
break;
|
|
|
|
|
2005-03-14 01:19:37 +01:00
|
|
|
case T_AlterFunctionStmt:
|
|
|
|
tag = "ALTER FUNCTION";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_GrantStmt:
|
|
|
|
{
|
|
|
|
GrantStmt *stmt = (GrantStmt *) parsetree;
|
|
|
|
|
|
|
|
tag = (stmt->is_grant) ? "GRANT" : "REVOKE";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_GrantRoleStmt:
|
|
|
|
{
|
2005-10-15 04:49:52 +02:00
|
|
|
GrantRoleStmt *stmt = (GrantRoleStmt *) parsetree;
|
2005-06-28 07:09:14 +02:00
|
|
|
|
|
|
|
tag = (stmt->is_grant) ? "GRANT ROLE" : "REVOKE ROLE";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
case T_AlterDefaultPrivilegesStmt:
|
|
|
|
tag = "ALTER DEFAULT PRIVILEGES";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_DefineStmt:
|
|
|
|
switch (((DefineStmt *) parsetree)->kind)
|
|
|
|
{
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_AGGREGATE:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "CREATE AGGREGATE";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_OPERATOR:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "CREATE OPERATOR";
|
|
|
|
break;
|
2003-06-27 16:45:32 +02:00
|
|
|
case OBJECT_TYPE:
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "CREATE TYPE";
|
|
|
|
break;
|
2007-08-21 03:11:32 +02:00
|
|
|
case OBJECT_TSPARSER:
|
|
|
|
tag = "CREATE TEXT SEARCH PARSER";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSDICTIONARY:
|
|
|
|
tag = "CREATE TEXT SEARCH DICTIONARY";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSTEMPLATE:
|
|
|
|
tag = "CREATE TEXT SEARCH TEMPLATE";
|
|
|
|
break;
|
|
|
|
case OBJECT_TSCONFIGURATION:
|
|
|
|
tag = "CREATE TEXT SEARCH CONFIGURATION";
|
|
|
|
break;
|
2011-02-12 14:54:13 +01:00
|
|
|
case OBJECT_COLLATION:
|
|
|
|
tag = "CREATE COLLATION";
|
|
|
|
break;
|
2003-05-02 22:54:36 +02:00
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CompositeTypeStmt:
|
|
|
|
tag = "CREATE TYPE";
|
|
|
|
break;
|
|
|
|
|
2007-04-02 05:49:42 +02:00
|
|
|
case T_CreateEnumStmt:
|
|
|
|
tag = "CREATE TYPE";
|
|
|
|
break;
|
|
|
|
|
2011-11-03 12:16:28 +01:00
|
|
|
case T_CreateRangeStmt:
|
|
|
|
tag = "CREATE TYPE";
|
|
|
|
break;
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
case T_AlterEnumStmt:
|
|
|
|
tag = "ALTER TYPE";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_ViewStmt:
|
|
|
|
tag = "CREATE VIEW";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateFunctionStmt:
|
|
|
|
tag = "CREATE FUNCTION";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_IndexStmt:
|
|
|
|
tag = "CREATE INDEX";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RuleStmt:
|
|
|
|
tag = "CREATE RULE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateSeqStmt:
|
|
|
|
tag = "CREATE SEQUENCE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterSeqStmt:
|
|
|
|
tag = "ALTER SEQUENCE";
|
|
|
|
break;
|
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
case T_DoStmt:
|
|
|
|
tag = "DO";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_CreatedbStmt:
|
|
|
|
tag = "CREATE DATABASE";
|
|
|
|
break;
|
|
|
|
|
2005-07-31 19:19:22 +02:00
|
|
|
case T_AlterDatabaseStmt:
|
|
|
|
tag = "ALTER DATABASE";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_AlterDatabaseSetStmt:
|
|
|
|
tag = "ALTER DATABASE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropdbStmt:
|
|
|
|
tag = "DROP DATABASE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_NotifyStmt:
|
|
|
|
tag = "NOTIFY";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ListenStmt:
|
|
|
|
tag = "LISTEN";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_UnlistenStmt:
|
|
|
|
tag = "UNLISTEN";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_LoadStmt:
|
|
|
|
tag = "LOAD";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ClusterStmt:
|
|
|
|
tag = "CLUSTER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VacuumStmt:
|
2009-11-16 22:32:07 +01:00
|
|
|
if (((VacuumStmt *) parsetree)->options & VACOPT_VACUUM)
|
2003-05-02 22:54:36 +02:00
|
|
|
tag = "VACUUM";
|
|
|
|
else
|
|
|
|
tag = "ANALYZE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExplainStmt:
|
|
|
|
tag = "EXPLAIN";
|
|
|
|
break;
|
|
|
|
|
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
|
|
|
case T_CreateTableAsStmt:
|
2013-03-04 01:23:31 +01:00
|
|
|
switch (((CreateTableAsStmt *) parsetree)->relkind)
|
|
|
|
{
|
|
|
|
case OBJECT_TABLE:
|
|
|
|
if (((CreateTableAsStmt *) parsetree)->is_select_into)
|
|
|
|
tag = "SELECT INTO";
|
|
|
|
else
|
|
|
|
tag = "CREATE TABLE AS";
|
|
|
|
break;
|
|
|
|
case OBJECT_MATVIEW:
|
|
|
|
tag = "CREATE MATERIALIZED VIEW";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RefreshMatViewStmt:
|
|
|
|
tag = "REFRESH MATERIALIZED VIEW";
|
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
|
|
|
break;
|
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
case T_AlterSystemStmt:
|
|
|
|
tag = "ALTER SYSTEM";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_VariableSetStmt:
|
2007-09-03 20:46:30 +02:00
|
|
|
switch (((VariableSetStmt *) parsetree)->kind)
|
|
|
|
{
|
|
|
|
case VAR_SET_VALUE:
|
|
|
|
case VAR_SET_CURRENT:
|
|
|
|
case VAR_SET_DEFAULT:
|
|
|
|
case VAR_SET_MULTI:
|
|
|
|
tag = "SET";
|
|
|
|
break;
|
|
|
|
case VAR_RESET:
|
|
|
|
case VAR_RESET_ALL:
|
|
|
|
tag = "RESET";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
tag = "???";
|
|
|
|
}
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VariableShowStmt:
|
|
|
|
tag = "SHOW";
|
|
|
|
break;
|
|
|
|
|
2007-04-26 18:13:15 +02:00
|
|
|
case T_DiscardStmt:
|
2007-09-03 20:46:30 +02:00
|
|
|
switch (((DiscardStmt *) parsetree)->target)
|
|
|
|
{
|
2007-04-26 18:13:15 +02:00
|
|
|
case DISCARD_ALL:
|
|
|
|
tag = "DISCARD ALL";
|
|
|
|
break;
|
|
|
|
case DISCARD_PLANS:
|
|
|
|
tag = "DISCARD PLANS";
|
|
|
|
break;
|
|
|
|
case DISCARD_TEMP:
|
|
|
|
tag = "DISCARD TEMP";
|
|
|
|
break;
|
2013-10-03 22:17:18 +02:00
|
|
|
case DISCARD_SEQUENCES:
|
|
|
|
tag = "DISCARD SEQUENCES";
|
|
|
|
break;
|
2007-04-26 18:13:15 +02:00
|
|
|
default:
|
|
|
|
tag = "???";
|
2007-04-12 08:53:49 +02:00
|
|
|
}
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
case T_CreateTransformStmt:
|
|
|
|
tag = "CREATE TRANSFORM";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_CreateTrigStmt:
|
|
|
|
tag = "CREATE TRIGGER";
|
|
|
|
break;
|
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
case T_CreateEventTrigStmt:
|
|
|
|
tag = "CREATE EVENT TRIGGER";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterEventTrigStmt:
|
|
|
|
tag = "ALTER EVENT TRIGGER";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_CreatePLangStmt:
|
|
|
|
tag = "CREATE LANGUAGE";
|
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_CreateRoleStmt:
|
|
|
|
tag = "CREATE ROLE";
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_AlterRoleStmt:
|
|
|
|
tag = "ALTER ROLE";
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_AlterRoleSetStmt:
|
|
|
|
tag = "ALTER ROLE";
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2005-06-28 07:09:14 +02:00
|
|
|
case T_DropRoleStmt:
|
|
|
|
tag = "DROP ROLE";
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
case T_DropOwnedStmt:
|
|
|
|
tag = "DROP OWNED";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ReassignOwnedStmt:
|
|
|
|
tag = "REASSIGN OWNED";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_LockStmt:
|
|
|
|
tag = "LOCK TABLE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ConstraintsSetStmt:
|
|
|
|
tag = "SET CONSTRAINTS";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CheckPointStmt:
|
|
|
|
tag = "CHECKPOINT";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ReindexStmt:
|
|
|
|
tag = "REINDEX";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateConversionStmt:
|
|
|
|
tag = "CREATE CONVERSION";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateCastStmt:
|
|
|
|
tag = "CREATE CAST";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateOpClassStmt:
|
|
|
|
tag = "CREATE OPERATOR CLASS";
|
|
|
|
break;
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
case T_CreateOpFamilyStmt:
|
|
|
|
tag = "CREATE OPERATOR FAMILY";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterOpFamilyStmt:
|
|
|
|
tag = "ALTER OPERATOR FAMILY";
|
|
|
|
break;
|
|
|
|
|
2015-07-14 17:17:55 +02:00
|
|
|
case T_AlterOperatorStmt:
|
|
|
|
tag = "ALTER OPERATOR";
|
|
|
|
break;
|
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
case T_AlterTSDictionaryStmt:
|
|
|
|
tag = "ALTER TEXT SEARCH DICTIONARY";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterTSConfigurationStmt:
|
|
|
|
tag = "ALTER TEXT SEARCH CONFIGURATION";
|
|
|
|
break;
|
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case T_CreatePolicyStmt:
|
|
|
|
tag = "CREATE POLICY";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterPolicyStmt:
|
|
|
|
tag = "ALTER POLICY";
|
|
|
|
break;
|
|
|
|
|
2003-05-02 22:54:36 +02:00
|
|
|
case T_PrepareStmt:
|
|
|
|
tag = "PREPARE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExecuteStmt:
|
|
|
|
tag = "EXECUTE";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeallocateStmt:
|
2007-04-12 08:53:49 +02:00
|
|
|
{
|
|
|
|
DeallocateStmt *stmt = (DeallocateStmt *) parsetree;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-04-12 08:53:49 +02:00
|
|
|
if (stmt->name == NULL)
|
|
|
|
tag = "DEALLOCATE ALL";
|
|
|
|
else
|
|
|
|
tag = "DEALLOCATE";
|
|
|
|
}
|
2003-05-02 22:54:36 +02:00
|
|
|
break;
|
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* already-planned queries */
|
2007-02-20 18:32:18 +01:00
|
|
|
case T_PlannedStmt:
|
|
|
|
{
|
|
|
|
PlannedStmt *stmt = (PlannedStmt *) parsetree;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
switch (stmt->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
/*
|
|
|
|
* We take a little extra care here so that the result
|
|
|
|
* will be useful for complaints about read-only
|
|
|
|
* statements
|
|
|
|
*/
|
2007-04-28 00:05:49 +02:00
|
|
|
if (stmt->utilityStmt != NULL)
|
|
|
|
{
|
|
|
|
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
|
|
|
|
tag = "DECLARE CURSOR";
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
else if (stmt->rowMarks != NIL)
|
|
|
|
{
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
/* not 100% but probably close enough */
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
switch (((PlanRowMark *) linitial(stmt->rowMarks))->strength)
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
{
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
case LCS_FORKEYSHARE:
|
|
|
|
tag = "SELECT FOR KEY SHARE";
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
break;
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
case LCS_FORSHARE:
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
tag = "SELECT FOR SHARE";
|
|
|
|
break;
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
case LCS_FORNOKEYUPDATE:
|
|
|
|
tag = "SELECT FOR NO KEY UPDATE";
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
break;
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
case LCS_FORUPDATE:
|
|
|
|
tag = "SELECT FOR UPDATE";
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
break;
|
|
|
|
default:
|
Improve representation of PlanRowMark.
This patch fixes two inadequacies of the PlanRowMark representation.
First, that the original LockingClauseStrength isn't stored (and cannot be
inferred for foreign tables, which always get ROW_MARK_COPY). Since some
PlanRowMarks are created out of whole cloth and don't actually have an
ancestral RowMarkClause, this requires adding a dummy LCS_NONE value to
enum LockingClauseStrength, which is fairly annoying but the alternatives
seem worse. This fix allows getting rid of the use of get_parse_rowmark()
in FDWs (as per the discussion around commits 462bd95705a0c23b and
8ec8760fc87ecde0), and it simplifies some things elsewhere.
Second, that the representation assumed that all child tables in an
inheritance hierarchy would use the same RowMarkType. That's true today
but will soon not be true. We add an "allMarkTypes" field that identifies
the union of mark types used in all a parent table's children, and use
that where appropriate (currently, only in preprocess_targetlist()).
In passing fix a couple of minor infelicities left over from the SKIP
LOCKED patch, notably that _outPlanRowMark still thought waitPolicy
is a bool.
Catversion bump is required because the numeric values of enum
LockingClauseStrength can appear in on-disk rules.
Extracted from a much larger patch to support foreign table inheritance;
it seemed worth breaking this out, since it's a separable concern.
Shigeru Hanada and Etsuro Fujita, somewhat modified by me
2015-03-15 23:41:47 +01:00
|
|
|
tag = "SELECT";
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
break;
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
tag = "SELECT";
|
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
|
|
|
tag = "UPDATE";
|
|
|
|
break;
|
|
|
|
case CMD_INSERT:
|
|
|
|
tag = "INSERT";
|
|
|
|
break;
|
|
|
|
case CMD_DELETE:
|
|
|
|
tag = "DELETE";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(WARNING, "unrecognized commandType: %d",
|
|
|
|
(int) stmt->commandType);
|
|
|
|
tag = "???";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2005-10-15 04:49:52 +02:00
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* parsed-and-rewritten-but-not-planned queries */
|
2007-02-20 18:32:18 +01:00
|
|
|
case T_Query:
|
2005-04-28 23:47:18 +02:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
Query *stmt = (Query *) parsetree;
|
2007-02-20 18:32:18 +01:00
|
|
|
|
|
|
|
switch (stmt->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
/*
|
|
|
|
* We take a little extra care here so that the result
|
|
|
|
* will be useful for complaints about read-only
|
|
|
|
* statements
|
|
|
|
*/
|
2007-04-28 00:05:49 +02:00
|
|
|
if (stmt->utilityStmt != NULL)
|
|
|
|
{
|
|
|
|
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
|
|
|
|
tag = "DECLARE CURSOR";
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
else if (stmt->rowMarks != NIL)
|
|
|
|
{
|
Re-implement EvalPlanQual processing to improve its performance and eliminate
a lot of strange behaviors that occurred in join cases. We now identify the
"current" row for every joined relation in UPDATE, DELETE, and SELECT FOR
UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the
appropriate row into each scan node in the rechecking plan, forcing it to emit
only that one row. The former behavior could rescan the whole of each joined
relation for each recheck, which was terrible for performance, and what's much
worse could result in duplicated output tuples.
Also, the original implementation of EvalPlanQual could not re-use the recheck
execution tree --- it had to go through a full executor init and shutdown for
every row to be tested. To avoid this overhead, I've associated a special
runtime Param with each LockRows or ModifyTable plan node, and arranged to
make every scan node below such a node depend on that Param. Thus, by
signaling a change in that Param, the EPQ machinery can just rescan the
already-built test plan.
This patch also adds a prohibition on set-returning functions in the
targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the
duplicate-output-tuple problem. It seems fairly reasonable since the
other restrictions on SELECT FOR UPDATE are meant to ensure that there
is a unique correspondence between source tuples and result tuples,
which an output SRF destroys as much as anything else does.
2009-10-26 03:26:45 +01:00
|
|
|
/* not 100% but probably close enough */
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
switch (((RowMarkClause *) linitial(stmt->rowMarks))->strength)
|
|
|
|
{
|
|
|
|
case LCS_FORKEYSHARE:
|
|
|
|
tag = "SELECT FOR KEY SHARE";
|
|
|
|
break;
|
|
|
|
case LCS_FORSHARE:
|
|
|
|
tag = "SELECT FOR SHARE";
|
|
|
|
break;
|
|
|
|
case LCS_FORNOKEYUPDATE:
|
|
|
|
tag = "SELECT FOR NO KEY UPDATE";
|
|
|
|
break;
|
|
|
|
case LCS_FORUPDATE:
|
|
|
|
tag = "SELECT FOR UPDATE";
|
|
|
|
break;
|
|
|
|
default:
|
2013-04-28 05:11:28 +02:00
|
|
|
tag = "???";
|
Improve concurrency of foreign key locking
This patch introduces two additional lock modes for tuples: "SELECT FOR
KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each
other, in contrast with already existing "SELECT FOR SHARE" and "SELECT
FOR UPDATE". UPDATE commands that do not modify the values stored in
the columns that are part of the key of the tuple now grab a SELECT FOR
NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently
with tuple locks of the FOR KEY SHARE variety.
Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this
means the concurrency improvement applies to them, which is the whole
point of this patch.
The added tuple lock semantics require some rejiggering of the multixact
module, so that the locking level that each transaction is holding can
be stored alongside its Xid. Also, multixacts now need to persist
across server restarts and crashes, because they can now represent not
only tuple locks, but also tuple updates. This means we need more
careful tracking of lifetime of pg_multixact SLRU files; since they now
persist longer, we require more infrastructure to figure out when they
can be removed. pg_upgrade also needs to be careful to copy
pg_multixact files over from the old server to the new, or at least part
of multixact.c state, depending on the versions of the old and new
servers.
Tuple time qualification rules (HeapTupleSatisfies routines) need to be
careful not to consider tuples with the "is multi" infomask bit set as
being only locked; they might need to look up MultiXact values (i.e.
possibly do pg_multixact I/O) to find out the Xid that updated a tuple,
whereas they previously were assured to only use information readily
available from the tuple header. This is considered acceptable, because
the extra I/O would involve cases that would previously cause some
commands to block waiting for concurrent transactions to finish.
Another important change is the fact that locking tuples that have
previously been updated causes the future versions to be marked as
locked, too; this is essential for correctness of foreign key checks.
This causes additional WAL-logging, also (there was previously a single
WAL record for a locked tuple; now there are as many as updated copies
of the tuple there exist.)
With all this in place, contention related to tuples being checked by
foreign key rules should be much reduced.
As a bonus, the old behavior that a subtransaction grabbing a stronger
tuple lock than the parent (sub)transaction held on a given tuple and
later aborting caused the weaker lock to be lost, has been fixed.
Many new spec files were added for isolation tester framework, to ensure
overall behavior is sane. There's probably room for several more tests.
There were several reviewers of this patch; in particular, Noah Misch
and Andres Freund spent considerable time in it. Original idea for the
patch came from Simon Riggs, after a problem report by Joel Jacobson.
Most code is from me, with contributions from Marti Raudsepp, Alexander
Shulgin, Noah Misch and Andres Freund.
This patch was discussed in several pgsql-hackers threads; the most
important start at the following message-ids:
AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com
1290721684-sup-3951@alvh.no-ip.org
1294953201-sup-2099@alvh.no-ip.org
1320343602-sup-2290@alvh.no-ip.org
1339690386-sup-8927@alvh.no-ip.org
4FE5FF020200002500048A3D@gw.wicourts.gov
4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 16:04:59 +01:00
|
|
|
break;
|
|
|
|
}
|
2007-02-20 18:32:18 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
tag = "SELECT";
|
|
|
|
break;
|
|
|
|
case CMD_UPDATE:
|
|
|
|
tag = "UPDATE";
|
|
|
|
break;
|
|
|
|
case CMD_INSERT:
|
|
|
|
tag = "INSERT";
|
|
|
|
break;
|
|
|
|
case CMD_DELETE:
|
|
|
|
tag = "DELETE";
|
|
|
|
break;
|
|
|
|
case CMD_UTILITY:
|
|
|
|
tag = CreateCommandTag(stmt->utilityStmt);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
elog(WARNING, "unrecognized commandType: %d",
|
|
|
|
(int) stmt->commandType);
|
|
|
|
tag = "???";
|
|
|
|
break;
|
|
|
|
}
|
2005-04-28 23:47:18 +02:00
|
|
|
}
|
2004-09-13 22:10:13 +02:00
|
|
|
break;
|
2007-02-20 18:32:18 +01:00
|
|
|
|
2004-09-13 22:10:13 +02:00
|
|
|
default:
|
2007-02-20 18:32:18 +01:00
|
|
|
elog(WARNING, "unrecognized node type: %d",
|
|
|
|
(int) nodeTag(parsetree));
|
2004-09-13 22:10:13 +02:00
|
|
|
tag = "???";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return tag;
|
|
|
|
}
|
2006-09-08 00:52:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GetCommandLogLevel
|
|
|
|
* utility to get the minimum log_statement level for a command,
|
2007-02-20 18:32:18 +01:00
|
|
|
* given either a raw (un-analyzed) parsetree or a planned query.
|
2006-09-08 00:52:01 +02:00
|
|
|
*
|
2007-02-20 18:32:18 +01:00
|
|
|
* This must handle all command types, but since the vast majority
|
2006-09-08 00:52:01 +02:00
|
|
|
* of 'em are utility commands, it seems sensible to keep it here.
|
|
|
|
*/
|
|
|
|
LogStmtLevel
|
|
|
|
GetCommandLogLevel(Node *parsetree)
|
|
|
|
{
|
|
|
|
LogStmtLevel lev;
|
|
|
|
|
|
|
|
switch (nodeTag(parsetree))
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
/* raw plannable queries */
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_InsertStmt:
|
|
|
|
case T_DeleteStmt:
|
|
|
|
case T_UpdateStmt:
|
|
|
|
lev = LOGSTMT_MOD;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_SelectStmt:
|
2007-04-28 00:05:49 +02:00
|
|
|
if (((SelectStmt *) parsetree)->intoClause)
|
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
|
|
|
lev = LOGSTMT_DDL; /* SELECT INTO */
|
2006-09-08 00:52:01 +02:00
|
|
|
else
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* utility statements --- same whether raw or cooked */
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_TransactionStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeclareCursorStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ClosePortalStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_FetchStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateSchemaStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateStmt:
|
2011-01-02 05:48:11 +01:00
|
|
|
case T_CreateForeignTableStmt:
|
2006-09-08 00:52:01 +02:00
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateTableSpaceStmt:
|
|
|
|
case T_DropTableSpaceStmt:
|
2010-01-05 22:54:00 +01:00
|
|
|
case T_AlterTableSpaceOptionsStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2011-02-08 22:08:41 +01:00
|
|
|
case T_CreateExtensionStmt:
|
2011-02-12 03:25:20 +01:00
|
|
|
case T_AlterExtensionStmt:
|
2011-02-10 23:36:44 +01:00
|
|
|
case T_AlterExtensionContentsStmt:
|
2011-02-08 22:08:41 +01:00
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2008-12-19 17:25:19 +01:00
|
|
|
case T_CreateFdwStmt:
|
|
|
|
case T_AlterFdwStmt:
|
|
|
|
case T_CreateForeignServerStmt:
|
|
|
|
case T_AlterForeignServerStmt:
|
|
|
|
case T_CreateUserMappingStmt:
|
|
|
|
case T_AlterUserMappingStmt:
|
|
|
|
case T_DropUserMappingStmt:
|
2014-07-10 21:01:31 +02:00
|
|
|
case T_ImportForeignSchemaStmt:
|
2008-12-19 17:25:19 +01:00
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_DropStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_TruncateStmt:
|
|
|
|
lev = LOGSTMT_MOD;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CommentStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
2010-09-28 02:55:27 +02:00
|
|
|
|
|
|
|
case T_SecLabelStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
|
|
|
case T_CopyStmt:
|
|
|
|
if (((CopyStmt *) parsetree)->is_from)
|
|
|
|
lev = LOGSTMT_MOD;
|
|
|
|
else
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2008-10-10 15:48:05 +02:00
|
|
|
case T_PrepareStmt:
|
|
|
|
{
|
|
|
|
PrepareStmt *stmt = (PrepareStmt *) parsetree;
|
|
|
|
|
|
|
|
/* Look through a PREPARE to the contained stmt */
|
|
|
|
lev = GetCommandLogLevel(stmt->query);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExecuteStmt:
|
|
|
|
{
|
|
|
|
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
|
|
|
|
PreparedStatement *ps;
|
|
|
|
|
|
|
|
/* Look through an EXECUTE to the referenced stmt */
|
|
|
|
ps = FetchPreparedStatement(stmt->name, false);
|
2014-11-12 21:58:37 +01:00
|
|
|
if (ps && ps->plansource->raw_parse_tree)
|
2008-10-10 15:48:05 +02:00
|
|
|
lev = GetCommandLogLevel(ps->plansource->raw_parse_tree);
|
|
|
|
else
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DeallocateStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_RenameStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterObjectSchemaStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterOwnerStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2014-08-22 01:06:17 +02:00
|
|
|
case T_AlterTableMoveAllStmt:
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_AlterTableStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterDomainStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_GrantStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_GrantRoleStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2009-10-05 21:24:49 +02:00
|
|
|
case T_AlterDefaultPrivilegesStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_DefineStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CompositeTypeStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2007-04-02 05:49:42 +02:00
|
|
|
case T_CreateEnumStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2011-11-03 12:16:28 +01:00
|
|
|
case T_CreateRangeStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
case T_AlterEnumStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_ViewStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateFunctionStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2008-10-10 15:48:05 +02:00
|
|
|
case T_AlterFunctionStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_IndexStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_RuleStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateSeqStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterSeqStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2009-09-23 01:43:43 +02:00
|
|
|
case T_DoStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_CreatedbStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterDatabaseStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterDatabaseSetStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropdbStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_NotifyStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ListenStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_UnlistenStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_LoadStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ClusterStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VacuumStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ExplainStmt:
|
|
|
|
{
|
2006-10-04 02:30:14 +02:00
|
|
|
ExplainStmt *stmt = (ExplainStmt *) parsetree;
|
2010-02-26 03:01:40 +01:00
|
|
|
bool analyze = false;
|
|
|
|
ListCell *lc;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
|
|
|
/* Look through an EXPLAIN ANALYZE to the contained stmt */
|
2009-07-27 01:34:18 +02:00
|
|
|
foreach(lc, stmt->options)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
DefElem *opt = (DefElem *) lfirst(lc);
|
2009-07-27 01:34:18 +02:00
|
|
|
|
|
|
|
if (strcmp(opt->defname, "analyze") == 0)
|
|
|
|
analyze = defGetBoolean(opt);
|
2010-01-15 23:36:35 +01:00
|
|
|
/* don't "break", as explain.c will use the last value */
|
2009-07-27 01:34:18 +02:00
|
|
|
}
|
|
|
|
if (analyze)
|
2007-03-13 01:33:44 +01:00
|
|
|
return GetCommandLogLevel(stmt->query);
|
2009-07-27 01:34:18 +02:00
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
/* Plain EXPLAIN isn't so interesting */
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
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
|
|
|
case T_CreateTableAsStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2013-03-04 01:23:31 +01:00
|
|
|
case T_RefreshMatViewStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2013-12-18 15:42:44 +01:00
|
|
|
case T_AlterSystemStmt:
|
2014-09-23 02:50:17 +02:00
|
|
|
lev = LOGSTMT_DDL;
|
2013-12-18 15:42:44 +01:00
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_VariableSetStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_VariableShowStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2008-10-10 15:48:05 +02:00
|
|
|
case T_DiscardStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_CreateTrigStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2012-07-18 16:16:16 +02:00
|
|
|
case T_CreateEventTrigStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterEventTrigStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_CreatePLangStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2008-10-10 15:48:05 +02:00
|
|
|
case T_CreateDomainStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2006-09-08 00:52:01 +02:00
|
|
|
case T_CreateRoleStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterRoleStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterRoleSetStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropRoleStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_DropOwnedStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ReassignOwnedStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_LockStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ConstraintsSetStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CheckPointStmt:
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_ReindexStmt:
|
2006-10-04 02:30:14 +02:00
|
|
|
lev = LOGSTMT_ALL; /* should this be DDL? */
|
2006-09-08 00:52:01 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateConversionStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateCastStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_CreateOpClassStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
case T_CreateOpFamilyStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2015-04-26 16:33:14 +02:00
|
|
|
case T_CreateTransformStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2007-01-23 06:07:18 +01:00
|
|
|
case T_AlterOpFamilyStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
case T_CreatePolicyStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterPolicyStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
case T_AlterTSDictionaryStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case T_AlterTSConfigurationStmt:
|
|
|
|
lev = LOGSTMT_DDL;
|
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* already-planned queries */
|
2007-02-20 18:32:18 +01:00
|
|
|
case T_PlannedStmt:
|
|
|
|
{
|
|
|
|
PlannedStmt *stmt = (PlannedStmt *) parsetree;
|
2006-10-04 02:30:14 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
switch (stmt->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
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
|
|
|
lev = LOGSTMT_ALL;
|
2007-02-20 18:32:18 +01:00
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
case CMD_UPDATE:
|
|
|
|
case CMD_INSERT:
|
|
|
|
case CMD_DELETE:
|
|
|
|
lev = LOGSTMT_MOD;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
elog(WARNING, "unrecognized commandType: %d",
|
|
|
|
(int) stmt->commandType);
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2006-09-08 00:52:01 +02:00
|
|
|
break;
|
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/* parsed-and-rewritten-but-not-planned queries */
|
2007-02-20 18:32:18 +01:00
|
|
|
case T_Query:
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
Query *stmt = (Query *) parsetree;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
switch (stmt->commandType)
|
|
|
|
{
|
|
|
|
case CMD_SELECT:
|
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
|
|
|
lev = LOGSTMT_ALL;
|
2007-02-20 18:32:18 +01:00
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
case CMD_UPDATE:
|
|
|
|
case CMD_INSERT:
|
|
|
|
case CMD_DELETE:
|
|
|
|
lev = LOGSTMT_MOD;
|
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
case CMD_UTILITY:
|
|
|
|
lev = GetCommandLogLevel(stmt->utilityStmt);
|
|
|
|
break;
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
default:
|
|
|
|
elog(WARNING, "unrecognized commandType: %d",
|
|
|
|
(int) stmt->commandType);
|
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
}
|
2006-09-08 00:52:01 +02:00
|
|
|
|
2007-02-20 18:32:18 +01:00
|
|
|
}
|
2006-09-08 00:52:01 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2007-02-20 18:32:18 +01:00
|
|
|
elog(WARNING, "unrecognized node type: %d",
|
|
|
|
(int) nodeTag(parsetree));
|
2006-09-08 00:52:01 +02:00
|
|
|
lev = LOGSTMT_ALL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return lev;
|
|
|
|
}
|