pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedCommand Triggers, patch v11
115+ messages / 9 participants
[nested] [flat]
* Command Triggers, patch v11
@ 2012-02-24 22:04 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-24 22:04 UTC (permalink / raw)
To: pgsql-hackers
Hi,
Please find attached the latest version of the command triggers patch,
in context diff format, with support for 79 commands and documentation
about why only those, and with some limitations explained.
I also cleaned up the node function support business that was still in
there from the command rewriting stuff that we dropped, and did a merge
from tonight's master branch (one of a few clean merges).
This is now the whole of it, and I continue being available to make any
necessary change, although I expect only minor changes now. Thanks to
all reviewers and participants into the previous threads, you all have
allowed me to reach the current point by your precious advice, comments
and interest.
The patch implements :
- BEFORE/AFTER ANY command triggers
- BEFORE/AFTER command triggers for 79 documented commands
- regression tests exercised by the serial schedule only
- documentation updates with examples
That means you need to `make installcheck` here. Installing the tests in
the parallel schedule does not lead to consistent output as installing a
command trigger will impact any other test using that command, and the
output becomes subject to the exact ordering of the concurrent tests.
The only way for a BEFORE command triggers to change the command's
behaviour is by raising an exception that aborts the whole transaction.
Command triggers are called with the following arguments:
- the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
- the command tag (the real one even when an ANY trigger is called)
- the object Id if available (e.g. NULL for a CREATE statement)
- the schema name (can be NULL)
- the object name (can be NULL)
When the trigger's procedure we're calling is written in C, then another
argument is passed next, which is the parse tree Node * pointer.
I've been talking with Marko Kreen about supporting ALTER TABLE and such
commands automatically in Londiste: given that patch, it requires
writing code in C that will rewrite the command string. It so happens
that I already have worked on that code, so we intend on bringing
support for ALTER TABLE and other commands in Skytools 3 for 9.2.
I think the support code should be made into an extension that both
Skytools and Slony would be able to share. The extension code will be
able to adapt to major versions changes as they are released. Bucardo
would certainly be interested too, we could NOTIFY it from such an
extension. The design is yet to be done here, but it's clearly possible
to implement such a feature given the current patch.
The ANY trigger support is mainly there to allow people to stop any DDL
traffic on their databases, then allowing it explicitly with an ALTER
COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
end, the ANY command trigger is supporting more commands than you can
attach specific triggers too.
It's also possible to ENABLE a command trigger on the REPLICA only
thanks to the session_replication_role GUC. Support for command
triggers on an Hot Standby node is not provided in this patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
command-trigger.v11.patch.gz (application/octet-stream, 58.2K) download
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-24 22:32 ` Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-24 22:32 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 24 February 2012 22:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Please find attached the latest version of the command triggers patch,
> in context diff format, with support for 79 commands and documentation
> about why only those, and with some limitations explained.
>
> I also cleaned up the node function support business that was still in
> there from the command rewriting stuff that we dropped, and did a merge
> from tonight's master branch (one of a few clean merges).
>
> This is now the whole of it, and I continue being available to make any
> necessary change, although I expect only minor changes now. Thanks to
> all reviewers and participants into the previous threads, you all have
> allowed me to reach the current point by your precious advice, comments
> and interest.
>
> The patch implements :
>
> - BEFORE/AFTER ANY command triggers
> - BEFORE/AFTER command triggers for 79 documented commands
> - regression tests exercised by the serial schedule only
> - documentation updates with examples
>
> That means you need to `make installcheck` here. Installing the tests in
> the parallel schedule does not lead to consistent output as installing a
> command trigger will impact any other test using that command, and the
> output becomes subject to the exact ordering of the concurrent tests.
>
> The only way for a BEFORE command triggers to change the command's
> behaviour is by raising an exception that aborts the whole transaction.
>
> Command triggers are called with the following arguments:
>
> - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
> - the command tag (the real one even when an ANY trigger is called)
> - the object Id if available (e.g. NULL for a CREATE statement)
> - the schema name (can be NULL)
> - the object name (can be NULL)
>
> When the trigger's procedure we're calling is written in C, then another
> argument is passed next, which is the parse tree Node * pointer.
>
> I've been talking with Marko Kreen about supporting ALTER TABLE and such
> commands automatically in Londiste: given that patch, it requires
> writing code in C that will rewrite the command string. It so happens
> that I already have worked on that code, so we intend on bringing
> support for ALTER TABLE and other commands in Skytools 3 for 9.2.
>
> I think the support code should be made into an extension that both
> Skytools and Slony would be able to share. The extension code will be
> able to adapt to major versions changes as they are released. Bucardo
> would certainly be interested too, we could NOTIFY it from such an
> extension. The design is yet to be done here, but it's clearly possible
> to implement such a feature given the current patch.
>
> The ANY trigger support is mainly there to allow people to stop any DDL
> traffic on their databases, then allowing it explicitly with an ALTER
> COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
> end, the ANY command trigger is supporting more commands than you can
> attach specific triggers too.
>
> It's also possible to ENABLE a command trigger on the REPLICA only
> thanks to the session_replication_role GUC. Support for command
> triggers on an Hot Standby node is not provided in this patch.
Hi Dimitri,
I just tried building the docs with your patch and it appears
doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
references for alterCommandTrigger, createCommandTrigger and
dropCommandTrigger.
Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
be orphaned text in the file too, such as "Forbids the execution of
any DDL command". And there's a stray </para> on line 299.
I attach updated versions of both of those files, which seems to fix
all these problems.
--
Thom
Attachments:
allfiles.sgml (text/sgml, 9.8K) download
<!--
doc/src/sgml/ref/allfiles.sgml
PostgreSQL documentation
Complete list of usable sgml source files in this directory.
-->
<!-- SQL commands -->
<!ENTITY abort SYSTEM "abort.sgml">
<!ENTITY alterAggregate SYSTEM "alter_aggregate.sgml">
<!ENTITY alterCollation SYSTEM "alter_collation.sgml">
<!ENTITY alterCommandTrigger SYSTEM "alter_command_trigger.sgml">
<!ENTITY alterConversion SYSTEM "alter_conversion.sgml">
<!ENTITY alterDatabase SYSTEM "alter_database.sgml">
<!ENTITY alterDefaultPrivileges SYSTEM "alter_default_privileges.sgml">
<!ENTITY alterDomain SYSTEM "alter_domain.sgml">
<!ENTITY alterExtension SYSTEM "alter_extension.sgml">
<!ENTITY alterForeignDataWrapper SYSTEM "alter_foreign_data_wrapper.sgml">
<!ENTITY alterForeignTable SYSTEM "alter_foreign_table.sgml">
<!ENTITY alterFunction SYSTEM "alter_function.sgml">
<!ENTITY alterGroup SYSTEM "alter_group.sgml">
<!ENTITY alterIndex SYSTEM "alter_index.sgml">
<!ENTITY alterLanguage SYSTEM "alter_language.sgml">
<!ENTITY alterLargeObject SYSTEM "alter_large_object.sgml">
<!ENTITY alterOperator SYSTEM "alter_operator.sgml">
<!ENTITY alterOperatorClass SYSTEM "alter_opclass.sgml">
<!ENTITY alterOperatorFamily SYSTEM "alter_opfamily.sgml">
<!ENTITY alterRole SYSTEM "alter_role.sgml">
<!ENTITY alterSchema SYSTEM "alter_schema.sgml">
<!ENTITY alterServer SYSTEM "alter_server.sgml">
<!ENTITY alterSequence SYSTEM "alter_sequence.sgml">
<!ENTITY alterTable SYSTEM "alter_table.sgml">
<!ENTITY alterTableSpace SYSTEM "alter_tablespace.sgml">
<!ENTITY alterTSConfig SYSTEM "alter_tsconfig.sgml">
<!ENTITY alterTSDictionary SYSTEM "alter_tsdictionary.sgml">
<!ENTITY alterTSParser SYSTEM "alter_tsparser.sgml">
<!ENTITY alterTSTemplate SYSTEM "alter_tstemplate.sgml">
<!ENTITY alterTrigger SYSTEM "alter_trigger.sgml">
<!ENTITY alterType SYSTEM "alter_type.sgml">
<!ENTITY alterUser SYSTEM "alter_user.sgml">
<!ENTITY alterUserMapping SYSTEM "alter_user_mapping.sgml">
<!ENTITY alterView SYSTEM "alter_view.sgml">
<!ENTITY analyze SYSTEM "analyze.sgml">
<!ENTITY begin SYSTEM "begin.sgml">
<!ENTITY checkpoint SYSTEM "checkpoint.sgml">
<!ENTITY close SYSTEM "close.sgml">
<!ENTITY cluster SYSTEM "cluster.sgml">
<!ENTITY commentOn SYSTEM "comment.sgml">
<!ENTITY commit SYSTEM "commit.sgml">
<!ENTITY commitPrepared SYSTEM "commit_prepared.sgml">
<!ENTITY copyTable SYSTEM "copy.sgml">
<!ENTITY createAggregate SYSTEM "create_aggregate.sgml">
<!ENTITY createCast SYSTEM "create_cast.sgml">
<!ENTITY createCollation SYSTEM "create_collation.sgml">
<!ENTITY createCommandTrigger SYSTEM "create_command_trigger.sgml">
<!ENTITY createConversion SYSTEM "create_conversion.sgml">
<!ENTITY createDatabase SYSTEM "create_database.sgml">
<!ENTITY createDomain SYSTEM "create_domain.sgml">
<!ENTITY createExtension SYSTEM "create_extension.sgml">
<!ENTITY createForeignDataWrapper SYSTEM "create_foreign_data_wrapper.sgml">
<!ENTITY createForeignTable SYSTEM "create_foreign_table.sgml">
<!ENTITY createFunction SYSTEM "create_function.sgml">
<!ENTITY createGroup SYSTEM "create_group.sgml">
<!ENTITY createIndex SYSTEM "create_index.sgml">
<!ENTITY createLanguage SYSTEM "create_language.sgml">
<!ENTITY createOperator SYSTEM "create_operator.sgml">
<!ENTITY createOperatorClass SYSTEM "create_opclass.sgml">
<!ENTITY createOperatorFamily SYSTEM "create_opfamily.sgml">
<!ENTITY createRole SYSTEM "create_role.sgml">
<!ENTITY createRule SYSTEM "create_rule.sgml">
<!ENTITY createSchema SYSTEM "create_schema.sgml">
<!ENTITY createSequence SYSTEM "create_sequence.sgml">
<!ENTITY createServer SYSTEM "create_server.sgml">
<!ENTITY createTable SYSTEM "create_table.sgml">
<!ENTITY createTableAs SYSTEM "create_table_as.sgml">
<!ENTITY createTableSpace SYSTEM "create_tablespace.sgml">
<!ENTITY createTrigger SYSTEM "create_trigger.sgml">
<!ENTITY createTSConfig SYSTEM "create_tsconfig.sgml">
<!ENTITY createTSDictionary SYSTEM "create_tsdictionary.sgml">
<!ENTITY createTSParser SYSTEM "create_tsparser.sgml">
<!ENTITY createTSTemplate SYSTEM "create_tstemplate.sgml">
<!ENTITY createType SYSTEM "create_type.sgml">
<!ENTITY createUser SYSTEM "create_user.sgml">
<!ENTITY createUserMapping SYSTEM "create_user_mapping.sgml">
<!ENTITY createView SYSTEM "create_view.sgml">
<!ENTITY deallocate SYSTEM "deallocate.sgml">
<!ENTITY declare SYSTEM "declare.sgml">
<!ENTITY delete SYSTEM "delete.sgml">
<!ENTITY discard SYSTEM "discard.sgml">
<!ENTITY do SYSTEM "do.sgml">
<!ENTITY dropAggregate SYSTEM "drop_aggregate.sgml">
<!ENTITY dropCast SYSTEM "drop_cast.sgml">
<!ENTITY dropCollation SYSTEM "drop_collation.sgml">
<!ENTITY dropCommandTrigger SYSTEM "drop_command_trigger.sgml">
<!ENTITY dropConversion SYSTEM "drop_conversion.sgml">
<!ENTITY dropDatabase SYSTEM "drop_database.sgml">
<!ENTITY dropDomain SYSTEM "drop_domain.sgml">
<!ENTITY dropExtension SYSTEM "drop_extension.sgml">
<!ENTITY dropForeignDataWrapper SYSTEM "drop_foreign_data_wrapper.sgml">
<!ENTITY dropForeignTable SYSTEM "drop_foreign_table.sgml">
<!ENTITY dropFunction SYSTEM "drop_function.sgml">
<!ENTITY dropGroup SYSTEM "drop_group.sgml">
<!ENTITY dropIndex SYSTEM "drop_index.sgml">
<!ENTITY dropLanguage SYSTEM "drop_language.sgml">
<!ENTITY dropOperator SYSTEM "drop_operator.sgml">
<!ENTITY dropOperatorClass SYSTEM "drop_opclass.sgml">
<!ENTITY dropOperatorFamily SYSTEM "drop_opfamily.sgml">
<!ENTITY dropOwned SYSTEM "drop_owned.sgml">
<!ENTITY dropRole SYSTEM "drop_role.sgml">
<!ENTITY dropRule SYSTEM "drop_rule.sgml">
<!ENTITY dropSchema SYSTEM "drop_schema.sgml">
<!ENTITY dropSequence SYSTEM "drop_sequence.sgml">
<!ENTITY dropServer SYSTEM "drop_server.sgml">
<!ENTITY dropTable SYSTEM "drop_table.sgml">
<!ENTITY dropTableSpace SYSTEM "drop_tablespace.sgml">
<!ENTITY dropTrigger SYSTEM "drop_trigger.sgml">
<!ENTITY dropTSConfig SYSTEM "drop_tsconfig.sgml">
<!ENTITY dropTSDictionary SYSTEM "drop_tsdictionary.sgml">
<!ENTITY dropTSParser SYSTEM "drop_tsparser.sgml">
<!ENTITY dropTSTemplate SYSTEM "drop_tstemplate.sgml">
<!ENTITY dropType SYSTEM "drop_type.sgml">
<!ENTITY dropUser SYSTEM "drop_user.sgml">
<!ENTITY dropUserMapping SYSTEM "drop_user_mapping.sgml">
<!ENTITY dropView SYSTEM "drop_view.sgml">
<!ENTITY end SYSTEM "end.sgml">
<!ENTITY execute SYSTEM "execute.sgml">
<!ENTITY explain SYSTEM "explain.sgml">
<!ENTITY fetch SYSTEM "fetch.sgml">
<!ENTITY grant SYSTEM "grant.sgml">
<!ENTITY insert SYSTEM "insert.sgml">
<!ENTITY listen SYSTEM "listen.sgml">
<!ENTITY load SYSTEM "load.sgml">
<!ENTITY lock SYSTEM "lock.sgml">
<!ENTITY move SYSTEM "move.sgml">
<!ENTITY notify SYSTEM "notify.sgml">
<!ENTITY prepare SYSTEM "prepare.sgml">
<!ENTITY prepareTransaction SYSTEM "prepare_transaction.sgml">
<!ENTITY reassignOwned SYSTEM "reassign_owned.sgml">
<!ENTITY reindex SYSTEM "reindex.sgml">
<!ENTITY releaseSavepoint SYSTEM "release_savepoint.sgml">
<!ENTITY reset SYSTEM "reset.sgml">
<!ENTITY revoke SYSTEM "revoke.sgml">
<!ENTITY rollback SYSTEM "rollback.sgml">
<!ENTITY rollbackPrepared SYSTEM "rollback_prepared.sgml">
<!ENTITY rollbackTo SYSTEM "rollback_to.sgml">
<!ENTITY savepoint SYSTEM "savepoint.sgml">
<!ENTITY securityLabel SYSTEM "security_label.sgml">
<!ENTITY select SYSTEM "select.sgml">
<!ENTITY selectInto SYSTEM "select_into.sgml">
<!ENTITY set SYSTEM "set.sgml">
<!ENTITY setConstraints SYSTEM "set_constraints.sgml">
<!ENTITY setRole SYSTEM "set_role.sgml">
<!ENTITY setSessionAuth SYSTEM "set_session_auth.sgml">
<!ENTITY setTransaction SYSTEM "set_transaction.sgml">
<!ENTITY show SYSTEM "show.sgml">
<!ENTITY startTransaction SYSTEM "start_transaction.sgml">
<!ENTITY truncate SYSTEM "truncate.sgml">
<!ENTITY unlisten SYSTEM "unlisten.sgml">
<!ENTITY update SYSTEM "update.sgml">
<!ENTITY vacuum SYSTEM "vacuum.sgml">
<!ENTITY values SYSTEM "values.sgml">
<!-- applications and utilities -->
<!ENTITY clusterdb SYSTEM "clusterdb.sgml">
<!ENTITY createdb SYSTEM "createdb.sgml">
<!ENTITY createlang SYSTEM "createlang.sgml">
<!ENTITY createuser SYSTEM "createuser.sgml">
<!ENTITY dropdb SYSTEM "dropdb.sgml">
<!ENTITY droplang SYSTEM "droplang.sgml">
<!ENTITY dropuser SYSTEM "dropuser.sgml">
<!ENTITY ecpgRef SYSTEM "ecpg-ref.sgml">
<!ENTITY initdb SYSTEM "initdb.sgml">
<!ENTITY pgBasebackup SYSTEM "pg_basebackup.sgml">
<!ENTITY pgConfig SYSTEM "pg_config-ref.sgml">
<!ENTITY pgControldata SYSTEM "pg_controldata.sgml">
<!ENTITY pgCtl SYSTEM "pg_ctl-ref.sgml">
<!ENTITY pgDump SYSTEM "pg_dump.sgml">
<!ENTITY pgDumpall SYSTEM "pg_dumpall.sgml">
<!ENTITY pgReceivexlog SYSTEM "pg_receivexlog.sgml">
<!ENTITY pgResetxlog SYSTEM "pg_resetxlog.sgml">
<!ENTITY pgRestore SYSTEM "pg_restore.sgml">
<!ENTITY postgres SYSTEM "postgres-ref.sgml">
<!ENTITY postmaster SYSTEM "postmaster.sgml">
<!ENTITY psqlRef SYSTEM "psql-ref.sgml">
<!ENTITY reindexdb SYSTEM "reindexdb.sgml">
<!ENTITY vacuumdb SYSTEM "vacuumdb.sgml">
create_command_trigger.sgml (text/sgml, 9.5K) download
<!--
doc/src/sgml/ref/create_trigger.sgml
PostgreSQL documentation
-->
<refentry id="SQL-CREATECOMMANDTRIGGER">
<refmeta>
<refentrytitle>CREATE COMMAND TRIGGER</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>CREATE COMMAND TRIGGER</refname>
<refpurpose>define a new trigger</refpurpose>
</refnamediv>
<indexterm zone="sql-createcommandtrigger">
<primary>CREATE COMMAND TRIGGER</primary>
</indexterm>
<refsynopsisdiv>
<synopsis>
CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTER } ANY COMMAND
EXECUTE PROCEDURE <replaceable class="PARAMETER">function_name</replaceable> ()
CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTER } COMMAND <replaceable class="PARAMETER">command</replaceable> [, ... ]
EXECUTE PROCEDURE <replaceable class="PARAMETER">function_name</replaceable> ()
<phrase>where <replaceable class="parameter">command</replaceable> can be one of:</phrase>
CREATE SCHEMA
CREATE EXTENSION
CREATE LANGUAGE
CREATE FUNCTION
CREATE TABLE
CREATE SERVER
CREATE FOREIGN TABLE
CREATE FOREIGN DATA WRAPPER
CREATE USER MAPPING
CREATE INDEX
CREATE SEQUENCE
CREATE VIEW
CREATE RULE
CREATE AGGREGATE
CREATE OPERATOR
CREATE COLLATION
CREATE TEXT SEARCH PARSER
CREATE TEXT SEARCH DICTIONARY
CREATE TEXT SEARCH TEMPLATE
CREATE TEXT SEARCH CONFIGURATION
CREATE TYPE_P
CREATE DOMAIN_P
CREATE TRIGGER
CREATE CONVERSION_P
CREATE CAST
CREATE OPERATOR CLASS
CREATE OPERATOR FAMILY
ALTER SCHEMA
ALTER EXTENSION
ALTER FUNCTION
ALTER TABLE
ALTER SERVER
ALTER FOREIGN TABLE
ALTER FOREIGN DATA WRAPPER
ALTER USER MAPPING
ALTER AGGREGATE
ALTER OPERATOR
ALTER OPERATOR CLASS
ALTER OPERATOR FAMILY
ALTER COLLATION
ALTER TEXT SEARCH PARSER
ALTER TEXT SEARCH DICTIONARY
ALTER TEXT SEARCH TEMPLATE
ALTER TEXT SEARCH CONFIGURATION
ALTER TYPE_P
ALTER DOMAIN_P
ALTER TRIGGER
DROP TABLE
DROP SEQUENCE
DROP VIEW
DROP INDEX
DROP TYPE_P
DROP DOMAIN_P
DROP COLLATION
DROP CONVERSION_P
DROP SCHEMA
DROP EXTENSION
DROP TEXT SEARCH PARSER
DROP TEXT SEARCH DICTIONARY
DROP TEXT SEARCH TEMPLATE
DROP TEXT SEARCH CONFIGURATION
DROP LANGUAGE
DROP SERVER
DROP FOREIGN TABLE
DROP FOREIGN DATA WRAPPER
DROP USER MAPPING
DROP TRIGGER
DROP ASSERTION
DROP OPERATOR CLASS
DROP OPERATOR FAMILY
DROP FUNCTION
DROP AGGREGATE
DROP OPERATOR
DROP CAST
DROP RULE
REINDEX
VACUUM
CLUSTER
LOAD
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>CREATE COMMAND TRIGGER</command> creates a new command trigger.
The trigger will be associated with the specified command and will
execute the specified
function <replaceable class="parameter">function_name</replaceable> when
that command is run.
</para>
<para>
The command trigger can be specified to fire before or after the command
is executed. A command trigger's function must
return <literal>void</literal>, the only it can aborts the execution of
the command is by raising an exception.
</para>
<para>
Refer to <xref linkend="triggers"> for more information about triggers.
</para>
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
The name to give the new trigger. This must be distinct from
the name of any other trigger for the same table.
The name cannot be schema-qualified — the trigger inherits the
schema of its table. For a constraint trigger, this is also the name to
use when modifying the trigger's behavior using
<command>SET CONSTRAINTS</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>BEFORE</literal></term>
<term><literal>AFTER</literal></term>
<listitem>
<para>
Determines whether the function is called before or after the command
is executed.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">command</replaceable></term>
<listitem>
<para>
The tag of the command the trigger is for. Supported commands are
mainly those acting on database objects, plus some more facilities.
That leaves out the following list of non supported commands.
</para>
<para>
Commands that refers to global objects, such as databases, tablespaces
and roles are not supported. As command triggers are per-database, it
would be weird to affect e.g. a tablespace depending on which database
you are connected to.
</para>
<para>
Commands that exercize their own transaction control are only
supported in <literal>BEFORE</literal> command triggers, that's the
case for <literal>VACUUM</literal>, <literal>CLUSTER</literal>
<literal>CREATE INDEX CONCURRENTLY</literal>, and <literal>REINDEX
DATABASE</literal>.
</para>
<para>
Commands that are related to transaction control (such
as <literal>BEGIN</literal> or <literal>COMMIT</literal>), related to
prepared plans
(e.g. <literal>PREPARE</literal>, <literal>DEALLOCATE</literal>),
cursors management
(e.g. <literal>DECLARE</literal>, <literal>FETCH</literal>), setting
variables (<literal>SET</literal>), the <literal>LISTEN</literal>
feature, and security are not supported either.
</para>
<para>
Command triggers on <literal>CREATE COMMAND
TRIGGER</literal>, <literal>ALTER COMMAND TRIGGER</literal>
and <literal>DROP COMMAND TRIGGER</literal> are not supported so as
not to be able to take over control from a superuser.
</para>
<para>
Triggers on <literal>ANY</literal> command support more commands than
just this list, and will only provide the <literal>command
tag</literal> argument as <literal>NOT NULL</literal>. Supporting more
commands is made so that you can actually block <xref linkend="ddl">
commands in one go.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">function_name</replaceable></term>
<listitem>
<para>
A user-supplied function that is declared as taking 5 arguments of
type text, text, oid, text, text and returning void.
</para>
<para>
If your command trigger is implemented in <literal>C</literal> then it
will be called with yet another argument, of
type <literal>internal</literal>, which is a pointer to
the <literal>Node *</literal> parse tree.
</para>
<para>
The command trigger function is called with the
parameters <literal>tg_when</literal> (which is set to either 'BEFORE'
or 'AFTER'), <literal>command
tag</literal>, <literal>objectid</literal> (can be null in case of a
BEFORE CREATE or an AFTER DROP command trigger
timing), <literal>schemaname</literal> (can be null for objects not
living in a schema, and for sequences due to an implementation limit)
and <literal>object name</literal> (can be null for any command
triggers).
</para>
<para>
The command <literal>CREATE SEQUENCE</literal> lacks support for
the <literal>schemaname</literal> command trigger argument, it
provides <literal>NULL</literal> in all cases.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1 id="SQL-CREATECOMMANDTRIGGER-notes">
<title>Notes</title>
<para>
To create a trigger on a command, the user must be superuser.
</para>
<para>
Use <xref linkend="sql-dropcommandtrigger"> to remove a command trigger.
</para>
</refsect1>
<refsect1 id="SQL-CREATECOMMANDTRIGGER-examples">
<title>Examples</title>
<para>
Forbids the execution of any DDL command:
</para>
<programlisting>
CREATE OR REPLACE FUNCTION abort_any_command
(tg_when text, cmd_tag text, objectid oid, schemaname text, objectname text)
RETURNS void LANGUAGE plpgsql AS $$
BEGIN
RAISE EXCEPTION 'command % is disabled' % cmd_tag;
END;
$$;
CREATE TRIGGER abort_ddl
BEFORE COMMAND CREATE TABLE
EXECUTE PROCEDURE abort_any_command();
</programlisting>
<para>
Execute the function <function>enforce_local_style</> each time
a <literal>CREATE TABLE</literal> command is run:
</para>
<programlisting>
CREATE OR REPLACE FUNCTION enforce_local_style
(tg_when text, cmd_tag text, objectid oid, schemaname text, objectname text)
RETURNS bool LANGUAGE plpgsql AS $$
BEGIN
IF substring(objectname, 0, 4) NOT IN ('ab_', 'cz_', 'fr_')
THEN
RAISE EXCEPTION 'invalid relation name: %', objectname;
END IF;
END;
$$;
CREATE TRIGGER check_style
BEFORE COMMAND CREATE TABLE
EXECUTE PROCEDURE enforce_local_style();
</programlisting>
</refsect1>
<refsect1 id="SQL-CREATECOMMANDTRIGGER-compatibility">
<title>Compatibility</title>
<para>
<command>CREATE COMMAND TRIGGER</command> is a
<productname>PostgreSQL</productname> extension of the <acronym>SQL</>
standard.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-createfunction"></member>
<member><xref linkend="sql-altercommandtrigger"></member>
<member><xref linkend="sql-dropcommandtrigger"></member>
</simplelist>
</refsect1>
</refentry>
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-24 22:39 ` Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-24 22:39 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 24 February 2012 22:32, Thom Brown <thom@linux.com> wrote:
> On 24 February 2012 22:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Hi,
>>
>> Please find attached the latest version of the command triggers patch,
>> in context diff format, with support for 79 commands and documentation
>> about why only those, and with some limitations explained.
>>
>> I also cleaned up the node function support business that was still in
>> there from the command rewriting stuff that we dropped, and did a merge
>> from tonight's master branch (one of a few clean merges).
>>
>> This is now the whole of it, and I continue being available to make any
>> necessary change, although I expect only minor changes now. Thanks to
>> all reviewers and participants into the previous threads, you all have
>> allowed me to reach the current point by your precious advice, comments
>> and interest.
>>
>> The patch implements :
>>
>> - BEFORE/AFTER ANY command triggers
>> - BEFORE/AFTER command triggers for 79 documented commands
>> - regression tests exercised by the serial schedule only
>> - documentation updates with examples
>>
>> That means you need to `make installcheck` here. Installing the tests in
>> the parallel schedule does not lead to consistent output as installing a
>> command trigger will impact any other test using that command, and the
>> output becomes subject to the exact ordering of the concurrent tests.
>>
>> The only way for a BEFORE command triggers to change the command's
>> behaviour is by raising an exception that aborts the whole transaction.
>>
>> Command triggers are called with the following arguments:
>>
>> - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
>> - the command tag (the real one even when an ANY trigger is called)
>> - the object Id if available (e.g. NULL for a CREATE statement)
>> - the schema name (can be NULL)
>> - the object name (can be NULL)
>>
>> When the trigger's procedure we're calling is written in C, then another
>> argument is passed next, which is the parse tree Node * pointer.
>>
>> I've been talking with Marko Kreen about supporting ALTER TABLE and such
>> commands automatically in Londiste: given that patch, it requires
>> writing code in C that will rewrite the command string. It so happens
>> that I already have worked on that code, so we intend on bringing
>> support for ALTER TABLE and other commands in Skytools 3 for 9.2.
>>
>> I think the support code should be made into an extension that both
>> Skytools and Slony would be able to share. The extension code will be
>> able to adapt to major versions changes as they are released. Bucardo
>> would certainly be interested too, we could NOTIFY it from such an
>> extension. The design is yet to be done here, but it's clearly possible
>> to implement such a feature given the current patch.
>>
>> The ANY trigger support is mainly there to allow people to stop any DDL
>> traffic on their databases, then allowing it explicitly with an ALTER
>> COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
>> end, the ANY command trigger is supporting more commands than you can
>> attach specific triggers too.
>>
>> It's also possible to ENABLE a command trigger on the REPLICA only
>> thanks to the session_replication_role GUC. Support for command
>> triggers on an Hot Standby node is not provided in this patch.
>
> Hi Dimitri,
>
> I just tried building the docs with your patch and it appears
> doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
> references for alterCommandTrigger, createCommandTrigger and
> dropCommandTrigger.
>
> Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
> Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
> be orphaned text in the file too, such as "Forbids the execution of
> any DDL command". And there's a stray </para> on line 299.
>
> I attach updated versions of both of those files, which seems to fix
> all these problems.
I've just noticed there's an issue with
doc/src/sgml/ref/alter_command_trigger.sgml too. It uses <indexterm
zone="sql-altertrigger"> which should be sql-altercommandtrigger. (as
attached)
--
Thom
Attachments:
alter_command_trigger.sgml (text/sgml, 2.3K) download
<!--
doc/src/sgml/ref/alter_trigger.sgml
PostgreSQL documentation
-->
<refentry id="SQL-ALTERCOMMANDTRIGGER">
<refmeta>
<refentrytitle>ALTER COMMAND TRIGGER</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>ALTER COMMAND TRIGGER</refname>
<refpurpose>change the definition of a trigger</refpurpose>
</refnamediv>
<indexterm zone="sql-altercommandtrigger">
<primary>ALTER COMMAND TRIGGER</primary>
</indexterm>
<refsynopsisdiv>
<synopsis>
ALTER COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> ON <replaceable class="PARAMETER">command</replaceable> SET <replaceable class="parameter">enabled</replaceable>
<phrase>where <replaceable class="parameter">enabled</replaceable> can be one of:</phrase>
ENABLE
ENABLE ALWAYS
ENABLE REPLICA
DISABLE
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>ALTER COMMAND TRIGGER</command> changes properties of an
existing command trigger.
</para>
<para>
You must be superuser to alter a command trigger.
</para>
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="PARAMETER">name</replaceable></term>
<listitem>
<para>
The name of an existing trigger to alter.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="PARAMETER">command</replaceable></term>
<listitem>
<para>
The command tag on which this trigger acts.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="PARAMETER">enabled</replaceable></term>
<listitem>
<para>
When to enable this trigger. See
the <literal>session_replication_role</literal> parameter.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
<command>ALTER COMMAND TRIGGER</command> is a <productname>PostgreSQL</>
extension of the SQL standard.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-createcommandtrigger"></member>
<member><xref linkend="sql-dropcommandtrigger"></member>
</simplelist>
</refsect1>
</refentry>
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-24 23:01 ` Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-24 23:01 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 24 February 2012 22:39, Thom Brown <thom@linux.com> wrote:
> On 24 February 2012 22:32, Thom Brown <thom@linux.com> wrote:
>> On 24 February 2012 22:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>> Hi,
>>>
>>> Please find attached the latest version of the command triggers patch,
>>> in context diff format, with support for 79 commands and documentation
>>> about why only those, and with some limitations explained.
>>>
>>> I also cleaned up the node function support business that was still in
>>> there from the command rewriting stuff that we dropped, and did a merge
>>> from tonight's master branch (one of a few clean merges).
>>>
>>> This is now the whole of it, and I continue being available to make any
>>> necessary change, although I expect only minor changes now. Thanks to
>>> all reviewers and participants into the previous threads, you all have
>>> allowed me to reach the current point by your precious advice, comments
>>> and interest.
>>>
>>> The patch implements :
>>>
>>> - BEFORE/AFTER ANY command triggers
>>> - BEFORE/AFTER command triggers for 79 documented commands
>>> - regression tests exercised by the serial schedule only
>>> - documentation updates with examples
>>>
>>> That means you need to `make installcheck` here. Installing the tests in
>>> the parallel schedule does not lead to consistent output as installing a
>>> command trigger will impact any other test using that command, and the
>>> output becomes subject to the exact ordering of the concurrent tests.
>>>
>>> The only way for a BEFORE command triggers to change the command's
>>> behaviour is by raising an exception that aborts the whole transaction.
>>>
>>> Command triggers are called with the following arguments:
>>>
>>> - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
>>> - the command tag (the real one even when an ANY trigger is called)
>>> - the object Id if available (e.g. NULL for a CREATE statement)
>>> - the schema name (can be NULL)
>>> - the object name (can be NULL)
>>>
>>> When the trigger's procedure we're calling is written in C, then another
>>> argument is passed next, which is the parse tree Node * pointer.
>>>
>>> I've been talking with Marko Kreen about supporting ALTER TABLE and such
>>> commands automatically in Londiste: given that patch, it requires
>>> writing code in C that will rewrite the command string. It so happens
>>> that I already have worked on that code, so we intend on bringing
>>> support for ALTER TABLE and other commands in Skytools 3 for 9.2.
>>>
>>> I think the support code should be made into an extension that both
>>> Skytools and Slony would be able to share. The extension code will be
>>> able to adapt to major versions changes as they are released. Bucardo
>>> would certainly be interested too, we could NOTIFY it from such an
>>> extension. The design is yet to be done here, but it's clearly possible
>>> to implement such a feature given the current patch.
>>>
>>> The ANY trigger support is mainly there to allow people to stop any DDL
>>> traffic on their databases, then allowing it explicitly with an ALTER
>>> COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
>>> end, the ANY command trigger is supporting more commands than you can
>>> attach specific triggers too.
>>>
>>> It's also possible to ENABLE a command trigger on the REPLICA only
>>> thanks to the session_replication_role GUC. Support for command
>>> triggers on an Hot Standby node is not provided in this patch.
>>
>> Hi Dimitri,
>>
>> I just tried building the docs with your patch and it appears
>> doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
>> references for alterCommandTrigger, createCommandTrigger and
>> dropCommandTrigger.
>>
>> Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
>> Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
>> be orphaned text in the file too, such as "Forbids the execution of
>> any DDL command". And there's a stray </para> on line 299.
>>
>> I attach updated versions of both of those files, which seems to fix
>> all these problems.
>
> I've just noticed there's an issue with
> doc/src/sgml/ref/alter_command_trigger.sgml too. It uses <indexterm
> zone="sql-altertrigger"> which should be sql-altercommandtrigger. (as
> attached)
And upon trying to test the actual feature, it didn't work for me at
all. I thought I had applied the patch incorrectly, but I hadn't, it
was the documentation showing the wrong information. The CREATE
COMMAND TRIGGER page actually just says CREATE TRIGGER.... BEFORE
COMMAND <command>, which isn't the correct syntax.
Also the examples on the page are incorrect in the same regard. When
I tested it with the correction, I got an error saying that the
function used had to return void, but the example uses bool. Upon
also changing this, the example works as expected.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-24 23:43 ` Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-24 23:43 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 24 February 2012 23:01, Thom Brown <thom@linux.com> wrote:
> On 24 February 2012 22:39, Thom Brown <thom@linux.com> wrote:
>> On 24 February 2012 22:32, Thom Brown <thom@linux.com> wrote:
>>> On 24 February 2012 22:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>> Hi,
>>>>
>>>> Please find attached the latest version of the command triggers patch,
>>>> in context diff format, with support for 79 commands and documentation
>>>> about why only those, and with some limitations explained.
>>>>
>>>> I also cleaned up the node function support business that was still in
>>>> there from the command rewriting stuff that we dropped, and did a merge
>>>> from tonight's master branch (one of a few clean merges).
>>>>
>>>> This is now the whole of it, and I continue being available to make any
>>>> necessary change, although I expect only minor changes now. Thanks to
>>>> all reviewers and participants into the previous threads, you all have
>>>> allowed me to reach the current point by your precious advice, comments
>>>> and interest.
>>>>
>>>> The patch implements :
>>>>
>>>> - BEFORE/AFTER ANY command triggers
>>>> - BEFORE/AFTER command triggers for 79 documented commands
>>>> - regression tests exercised by the serial schedule only
>>>> - documentation updates with examples
>>>>
>>>> That means you need to `make installcheck` here. Installing the tests in
>>>> the parallel schedule does not lead to consistent output as installing a
>>>> command trigger will impact any other test using that command, and the
>>>> output becomes subject to the exact ordering of the concurrent tests.
>>>>
>>>> The only way for a BEFORE command triggers to change the command's
>>>> behaviour is by raising an exception that aborts the whole transaction.
>>>>
>>>> Command triggers are called with the following arguments:
>>>>
>>>> - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
>>>> - the command tag (the real one even when an ANY trigger is called)
>>>> - the object Id if available (e.g. NULL for a CREATE statement)
>>>> - the schema name (can be NULL)
>>>> - the object name (can be NULL)
>>>>
>>>> When the trigger's procedure we're calling is written in C, then another
>>>> argument is passed next, which is the parse tree Node * pointer.
>>>>
>>>> I've been talking with Marko Kreen about supporting ALTER TABLE and such
>>>> commands automatically in Londiste: given that patch, it requires
>>>> writing code in C that will rewrite the command string. It so happens
>>>> that I already have worked on that code, so we intend on bringing
>>>> support for ALTER TABLE and other commands in Skytools 3 for 9.2.
>>>>
>>>> I think the support code should be made into an extension that both
>>>> Skytools and Slony would be able to share. The extension code will be
>>>> able to adapt to major versions changes as they are released. Bucardo
>>>> would certainly be interested too, we could NOTIFY it from such an
>>>> extension. The design is yet to be done here, but it's clearly possible
>>>> to implement such a feature given the current patch.
>>>>
>>>> The ANY trigger support is mainly there to allow people to stop any DDL
>>>> traffic on their databases, then allowing it explicitly with an ALTER
>>>> COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
>>>> end, the ANY command trigger is supporting more commands than you can
>>>> attach specific triggers too.
>>>>
>>>> It's also possible to ENABLE a command trigger on the REPLICA only
>>>> thanks to the session_replication_role GUC. Support for command
>>>> triggers on an Hot Standby node is not provided in this patch.
>>>
>>> Hi Dimitri,
>>>
>>> I just tried building the docs with your patch and it appears
>>> doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
>>> references for alterCommandTrigger, createCommandTrigger and
>>> dropCommandTrigger.
>>>
>>> Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
>>> Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
>>> be orphaned text in the file too, such as "Forbids the execution of
>>> any DDL command". And there's a stray </para> on line 299.
>>>
>>> I attach updated versions of both of those files, which seems to fix
>>> all these problems.
>>
>> I've just noticed there's an issue with
>> doc/src/sgml/ref/alter_command_trigger.sgml too. It uses <indexterm
>> zone="sql-altertrigger"> which should be sql-altercommandtrigger. (as
>> attached)
>
> And upon trying to test the actual feature, it didn't work for me at
> all. I thought I had applied the patch incorrectly, but I hadn't, it
> was the documentation showing the wrong information. The CREATE
> COMMAND TRIGGER page actually just says CREATE TRIGGER.... BEFORE
> COMMAND <command>, which isn't the correct syntax.
>
> Also the examples on the page are incorrect in the same regard. When
> I tested it with the correction, I got an error saying that the
> function used had to return void, but the example uses bool. Upon
> also changing this, the example works as expected.
Is there any reason why the list of commands that command triggers can
be used with isn't in alphabetical order? Also it appears to show
CREATE/ALTER/DROP TYPE_P, and the same for CONVERSION_P and DOMAIN_P.
I'm assuming these are typos? They also appear on DROP COMMAND
TRIGGER.
The ALTER COMMAND TRIGGER page also doesn't show which commands it can
be used against. Perhaps, rather than repeat the list, there could be
a note to say that a list of valid commands can be found on the CREATE
COMMAND TRIGGER page?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 11:58 ` Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-25 11:58 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 24 February 2012 23:43, Thom Brown <thom@linux.com> wrote:
> On 24 February 2012 23:01, Thom Brown <thom@linux.com> wrote:
>> On 24 February 2012 22:39, Thom Brown <thom@linux.com> wrote:
>>> On 24 February 2012 22:32, Thom Brown <thom@linux.com> wrote:
>>>> On 24 February 2012 22:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>> Hi,
>>>>>
>>>>> Please find attached the latest version of the command triggers patch,
>>>>> in context diff format, with support for 79 commands and documentation
>>>>> about why only those, and with some limitations explained.
>>>>>
>>>>> I also cleaned up the node function support business that was still in
>>>>> there from the command rewriting stuff that we dropped, and did a merge
>>>>> from tonight's master branch (one of a few clean merges).
>>>>>
>>>>> This is now the whole of it, and I continue being available to make any
>>>>> necessary change, although I expect only minor changes now. Thanks to
>>>>> all reviewers and participants into the previous threads, you all have
>>>>> allowed me to reach the current point by your precious advice, comments
>>>>> and interest.
>>>>>
>>>>> The patch implements :
>>>>>
>>>>> - BEFORE/AFTER ANY command triggers
>>>>> - BEFORE/AFTER command triggers for 79 documented commands
>>>>> - regression tests exercised by the serial schedule only
>>>>> - documentation updates with examples
>>>>>
>>>>> That means you need to `make installcheck` here. Installing the tests in
>>>>> the parallel schedule does not lead to consistent output as installing a
>>>>> command trigger will impact any other test using that command, and the
>>>>> output becomes subject to the exact ordering of the concurrent tests.
>>>>>
>>>>> The only way for a BEFORE command triggers to change the command's
>>>>> behaviour is by raising an exception that aborts the whole transaction.
>>>>>
>>>>> Command triggers are called with the following arguments:
>>>>>
>>>>> - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER')
>>>>> - the command tag (the real one even when an ANY trigger is called)
>>>>> - the object Id if available (e.g. NULL for a CREATE statement)
>>>>> - the schema name (can be NULL)
>>>>> - the object name (can be NULL)
>>>>>
>>>>> When the trigger's procedure we're calling is written in C, then another
>>>>> argument is passed next, which is the parse tree Node * pointer.
>>>>>
>>>>> I've been talking with Marko Kreen about supporting ALTER TABLE and such
>>>>> commands automatically in Londiste: given that patch, it requires
>>>>> writing code in C that will rewrite the command string. It so happens
>>>>> that I already have worked on that code, so we intend on bringing
>>>>> support for ALTER TABLE and other commands in Skytools 3 for 9.2.
>>>>>
>>>>> I think the support code should be made into an extension that both
>>>>> Skytools and Slony would be able to share. The extension code will be
>>>>> able to adapt to major versions changes as they are released. Bucardo
>>>>> would certainly be interested too, we could NOTIFY it from such an
>>>>> extension. The design is yet to be done here, but it's clearly possible
>>>>> to implement such a feature given the current patch.
>>>>>
>>>>> The ANY trigger support is mainly there to allow people to stop any DDL
>>>>> traffic on their databases, then allowing it explicitly with an ALTER
>>>>> COMMAND TRIGGER ... SET DISABLE when appropriate only. To that
>>>>> end, the ANY command trigger is supporting more commands than you can
>>>>> attach specific triggers too.
>>>>>
>>>>> It's also possible to ENABLE a command trigger on the REPLICA only
>>>>> thanks to the session_replication_role GUC. Support for command
>>>>> triggers on an Hot Standby node is not provided in this patch.
>>>>
>>>> Hi Dimitri,
>>>>
>>>> I just tried building the docs with your patch and it appears
>>>> doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
>>>> references for alterCommandTrigger, createCommandTrigger and
>>>> dropCommandTrigger.
>>>>
>>>> Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
>>>> Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
>>>> be orphaned text in the file too, such as "Forbids the execution of
>>>> any DDL command". And there's a stray </para> on line 299.
>>>>
>>>> I attach updated versions of both of those files, which seems to fix
>>>> all these problems.
>>>
>>> I've just noticed there's an issue with
>>> doc/src/sgml/ref/alter_command_trigger.sgml too. It uses <indexterm
>>> zone="sql-altertrigger"> which should be sql-altercommandtrigger. (as
>>> attached)
>>
>> And upon trying to test the actual feature, it didn't work for me at
>> all. I thought I had applied the patch incorrectly, but I hadn't, it
>> was the documentation showing the wrong information. The CREATE
>> COMMAND TRIGGER page actually just says CREATE TRIGGER.... BEFORE
>> COMMAND <command>, which isn't the correct syntax.
>>
>> Also the examples on the page are incorrect in the same regard. When
>> I tested it with the correction, I got an error saying that the
>> function used had to return void, but the example uses bool. Upon
>> also changing this, the example works as expected.
>
> Is there any reason why the list of commands that command triggers can
> be used with isn't in alphabetical order? Also it appears to show
> CREATE/ALTER/DROP TYPE_P, and the same for CONVERSION_P and DOMAIN_P.
> I'm assuming these are typos? They also appear on DROP COMMAND
> TRIGGER.
>
> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
> be used against. Perhaps, rather than repeat the list, there could be
> a note to say that a list of valid commands can be found on the CREATE
> COMMAND TRIGGER page?
I notice that DROP COMMAND TRIGGER requires the specification of every
command it was created against in order to drop it. So if I had:
CREATE COMMAND TRIGGER test_cmd_trg
BEFORE CREATE SCHEMA,
CREATE OPERATOR,
CREATE COLLATION,
CREATE CAST
EXECUTE PROCEDURE my_func();
I couldn't drop it completely unless I specified all of those commands. Why?
Incidentally, I've noticed the DROP COMMAND TRIGGER has a mistake in the syntax.
DROP COMMAND TRIGGER [ IF EXISTS ] name ON COMMAND command [, ... ] [
CASCADE | RESTRICT ]
Should be:
DROP COMMAND TRIGGER [ IF EXISTS ] name ON command [, ... ] [ CASCADE
| RESTRICT ]
The documentation also needs to cover the pg_cmdtrigger catalogue as
it's not mentioned anywhere.
I'm enjoying playing with this feature though btw. :)
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-27 19:37 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-27 19:37 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> CREATE COMMAND TRIGGER test_cmd_trg
> BEFORE CREATE SCHEMA,
> CREATE OPERATOR,
> CREATE COLLATION,
> CREATE CAST
> EXECUTE PROCEDURE my_func();
>
> I couldn't drop it completely unless I specified all of those commands. Why?
Because I couldn't find a nice enough way to implement that given the
shared infrastructure Robert and Kaigai did put into place to handle
dropping of objects. It could be that I didn't look hard enough, I'll
be happy to get back that feature.
> Incidentally, I've noticed the DROP COMMAND TRIGGER has a mistake in the syntax.
Thanks, fix will be in the next version.
> The documentation also needs to cover the pg_cmdtrigger catalogue as
> it's not mentioned anywhere.
That too, working on it now, adding forgotten forms you reported and
more, adding regression tests, fixing weird cases, getting there :)
> I'm enjoying playing with this feature though btw. :)
Thanks :)
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-28 11:43 ` Thom Brown <thom@linux.com>
2012-02-28 13:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-28 11:43 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 27 February 2012 19:37, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Thom Brown <thom@linux.com> writes:
>> CREATE COMMAND TRIGGER test_cmd_trg
>> BEFORE CREATE SCHEMA,
>> CREATE OPERATOR,
>> CREATE COLLATION,
>> CREATE CAST
>> EXECUTE PROCEDURE my_func();
>>
>> I couldn't drop it completely unless I specified all of those commands. Why?
>
> Because I couldn't find a nice enough way to implement that given the
> shared infrastructure Robert and Kaigai did put into place to handle
> dropping of objects. It could be that I didn't look hard enough, I'll
> be happy to get back that feature.
Well the problem is that you can add commands to a trigger en masse,
but you can only remove them one at a time. Couldn't we at least
allow the removal of multiple commands at the same time? The docs you
wrote suggest you can do this, but you can't.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-28 13:32 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-28 13:32 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 28 February 2012 11:43, Thom Brown <thom@linux.com> wrote:
> On 27 February 2012 19:37, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Thom Brown <thom@linux.com> writes:
>>> CREATE COMMAND TRIGGER test_cmd_trg
>>> BEFORE CREATE SCHEMA,
>>> CREATE OPERATOR,
>>> CREATE COLLATION,
>>> CREATE CAST
>>> EXECUTE PROCEDURE my_func();
>>>
>>> I couldn't drop it completely unless I specified all of those commands. Why?
>>
>> Because I couldn't find a nice enough way to implement that given the
>> shared infrastructure Robert and Kaigai did put into place to handle
>> dropping of objects. It could be that I didn't look hard enough, I'll
>> be happy to get back that feature.
>
> Well the problem is that you can add commands to a trigger en masse,
> but you can only remove them one at a time. Couldn't we at least
> allow the removal of multiple commands at the same time? The docs you
> wrote suggest you can do this, but you can't.
Also note that as of commit 66f0cf7da8eeaeca4b9894bfafd61789b514af4a
(Remove useless const qualifier) the patch no longer applies due to
changes to src/backend/commands/typecmds.c.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-28 15:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-02-28 15:14 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 3 replies; 115+ messages in thread
From: Tom Lane @ 2012-02-28 15:03 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> Well the problem is that you can add commands to a trigger en masse,
> but you can only remove them one at a time. Couldn't we at least
> allow the removal of multiple commands at the same time? The docs you
> wrote suggest you can do this, but you can't.
This seems over-complicated. Triggers on tables do not have alterable
properties, why should command triggers? I vote for
CREATE COMMAND TRIGGER name ... properties ...;
DROP COMMAND TRIGGER name;
full stop. If you want to run the same trigger function on some more
commands, add another trigger name.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-02-28 15:09 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2 siblings, 1 reply; 115+ messages in thread
From: Kevin Grittner @ 2012-02-28 15:09 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This seems over-complicated. Triggers on tables do not have
> alterable properties, why should command triggers? I vote for
>
> CREATE COMMAND TRIGGER name ... properties ...;
>
> DROP COMMAND TRIGGER name;
>
> full stop. If you want to run the same trigger function on some
> more commands, add another trigger name.
+1
-Kevin
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
@ 2012-03-03 00:12 ` Robert Haas <robertmhaas@gmail.com>
2012-03-03 13:45 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-03 00:12 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: Thom Brown <thom@linux.com>; Tom Lane <tgl@sss.pgh.pa.us>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
On Tue, Feb 28, 2012 at 10:09 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This seems over-complicated. Triggers on tables do not have
>> alterable properties, why should command triggers? I vote for
>>
>> CREATE COMMAND TRIGGER name ... properties ...;
>>
>> DROP COMMAND TRIGGER name;
>>
>> full stop. If you want to run the same trigger function on some
>> more commands, add another trigger name.
>
> +1
+1. I suggested the same thing a while back.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-03 13:45 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 14:03 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-03 13:45 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; Thom Brown <thom@linux.com>; Tom Lane <tgl@sss.pgh.pa.us>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>>> CREATE COMMAND TRIGGER name ... properties ...;
>>> DROP COMMAND TRIGGER name;
>>>
>>> full stop. If you want to run the same trigger function on some
>>> more commands, add another trigger name.
>>
>> +1
>
> +1. I suggested the same thing a while back.
Yeah, I know, I just wanted to hear from more people before ditching out
a part of the work I did, and Thom was balancing in the opposite
direction.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-03 13:45 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-03 14:03 ` Thom Brown <thom@linux.com>
2012-03-03 14:34 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-03 14:03 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Robert Haas <robertmhaas@gmail.com>; Kevin Grittner <Kevin.Grittner@wicourts.gov>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 3 March 2012 13:45, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>>> CREATE COMMAND TRIGGER name ... properties ...;
>>>> DROP COMMAND TRIGGER name;
>>>>
>>>> full stop. If you want to run the same trigger function on some
>>>> more commands, add another trigger name.
>>>
>>> +1
>>
>> +1. I suggested the same thing a while back.
>
> Yeah, I know, I just wanted to hear from more people before ditching out
> a part of the work I did, and Thom was balancing in the opposite
> direction.
I was? I agreed with Tom's comment, but I did query your
interpretation of it with regards to the CREATE COMMAND TRIGGER
statement. It seems you removed the ability to create a command
trigger against multiple commands, but I don't think that was the
problem. It was the DROP COMMAND TRIGGER statement that garnered
comment, as it makes more sense to drop the entire trigger than
individual commands for that trigger. Initially I had proposed a way
to drop all commands on a trigger at once as an additional option, but
just dropping it completely or not at all is preferable.
But if there is agreement to have multiple commands on a command
trigger, I'm wondering whether we should have an OR separator rather
than a comma? The reason is that regular triggers define a list of
statements this way. Personally I prefer the comma syntax, but my
concern (not a strong concern) is for lack of consistency.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-03 13:45 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 14:03 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-03 14:34 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 15:55 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-03 14:34 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; Robert Haas <robertmhaas@gmail.com>; Kevin Grittner <Kevin.Grittner@wicourts.gov>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> problem. It was the DROP COMMAND TRIGGER statement that garnered
> comment, as it makes more sense to drop the entire trigger than
> individual commands for that trigger.
What you're saying here is that a single command could have more than
one command attached to it, and what I understand Tom, Robert and Kevin
are saying is that any given command trigger should only be attached to
a single command.
If we wanted to be more consistent we would need to have a way to attach
the same trigger to both BEFORE and AFTER the command, as of now you
need two triggers here.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-03 13:45 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 14:03 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 14:34 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-03 15:55 ` Thom Brown <thom@linux.com>
0 siblings, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-03 15:55 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Robert Haas <robertmhaas@gmail.com>; Kevin Grittner <Kevin.Grittner@wicourts.gov>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 3 March 2012 14:34, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Thom Brown <thom@linux.com> writes:
>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>> comment, as it makes more sense to drop the entire trigger than
>> individual commands for that trigger.
>
> What you're saying here is that a single command could have more than
> one command attached to it, and what I understand Tom, Robert and Kevin
> are saying is that any given command trigger should only be attached to
> a single command.
I hadn't interpreted it that way, but then that could just be my
misinterpretation. I'm still of the opinion that a single command
trigger should be able to attach to multiple commands, just not
amendable once the trigger has been created. If that's not how others
saw it, I'm outnumbered.
So my vote was for:
CREATE COMMAND TRIGGER name { BEFORE | AFTER } command [, ... ]
EXECUTE PROCEDURE function_name ()
ALTER COMMAND TRIGGER name SET enabled
DROP COMMAND TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]
The only difference shown above compared to the current implementation
in your patch is [, ... ] after command in the CREATE COMMAND TRIGGER
statement.
My argument for this is that you may wish to implement the same
trigger for tables, views and foreign tables rather than create 3
separate triggers.
> If we wanted to be more consistent we would need to have a way to attach
> the same trigger to both BEFORE and AFTER the command, as of now you
> need two triggers here.
I'm not sure I understand. Attaching a trigger to both BEFORE and
AFTER isn't possible for regular triggers so I don't see why that
would introduce consistency. Could you explain?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-02-28 15:14 ` Thom Brown <thom@linux.com>
2 siblings, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-28 15:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
On 28 February 2012 15:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thom Brown <thom@linux.com> writes:
>> Well the problem is that you can add commands to a trigger en masse,
>> but you can only remove them one at a time. Couldn't we at least
>> allow the removal of multiple commands at the same time? The docs you
>> wrote suggest you can do this, but you can't.
>
> This seems over-complicated. Triggers on tables do not have alterable
> properties, why should command triggers? I vote for
>
> CREATE COMMAND TRIGGER name ... properties ...;
>
> DROP COMMAND TRIGGER name;
>
> full stop. If you want to run the same trigger function on some more
> commands, add another trigger name.
This would make more sense, particularly since dropping a command
trigger, as it stands, doesn't necessarily drop the trigger.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-02 22:32 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-02 22:32 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Hi,
Please find attached v13 of the command trigger patch, fixing most of
known items and rebased against master. Two important items remain to be
done, but I figured I should keep you posted in the meantime.
Tom Lane <tgl@sss.pgh.pa.us> writes:
> This seems over-complicated. Triggers on tables do not have alterable
> properties, why should command triggers? I vote for
>
> CREATE COMMAND TRIGGER name ... properties ...;
>
> DROP COMMAND TRIGGER name;
>
> full stop. If you want to run the same trigger function on some more
> commands, add another trigger name.
I reworked ALTER COMMAND TRIGGER and DROP COMMAND TRIGGER in the
attached, and the catalog too so that the command trigger's name is now
unique there. I added separate index on the command name.
Thom Brown <thom@linux.com> writes:
> Just so it's easy to scan. If someone is looking for CREATE CAST,
> they'd kind of expect it near the drop of the CREATE list, but it's
> actually toward the bottom. It just looks random at the moment.
I did M-x sort-lines in the documentation. Still have to add entries
for the new catalog though.
>> test=# CREATE TABLE badname (id int, a int, b text);
>> ERROR: invalid relation name: badname
>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>> SELECT 1
>>
>> This doesn't even get picked up by ANY COMMAND.
I think Andres should add an entry for his patch on the commitfest. Is
it ok?
> CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
> expect ALTER COMMAND TRIGGER to output too for when individual
> commands are disabled etc.
To be done in next patch's version, sorry about that.
Tom Lane <tgl@sss.pgh.pa.us> writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command triggers
> is nailed down and won't need to change in the future.
That too will need to wait for the next revision, it's just about
finding enough cycles, which is definitely happening very soon.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
command-trigger.v13.patch.gz (application/octet-stream, 62.7K) download
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-02 23:33 ` Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-02 23:33 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 2 March 2012 22:32, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Please find attached v13 of the command trigger patch, fixing most of
> known items and rebased against master. Two important items remain to be
> done, but I figured I should keep you posted in the meantime.
Thanks Dimitri. I'll give it a spin this weekend.
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> This seems over-complicated. Triggers on tables do not have alterable
>> properties, why should command triggers? I vote for
>>
>> CREATE COMMAND TRIGGER name ... properties ...;
>>
>> DROP COMMAND TRIGGER name;
>>
>> full stop. If you want to run the same trigger function on some more
>> commands, add another trigger name.
>
> I reworked ALTER COMMAND TRIGGER and DROP COMMAND TRIGGER in the
> attached, and the catalog too so that the command trigger's name is now
> unique there. I added separate index on the command name.
I see you now only allow a single command to be attached to a trigger
at creation time. I was actually fine with how it worked before, just
not with the DROP COMMAND. So, CREATE COMMAND TRIGGER could add a
trigger against several commands, but DROP COMMAND TRIGGER would drop
the whole lot as a single trigger rather than having the ability to
drop separate commands. This is how regular triggers work, in that
you can attach to several types of SQL statement, but you have to drop
the trigger as a whole rather than dropping individual statements.
Tom, could you clarify your suggestion for this? By "properties", do
you mean possibly several commands?
> Thom Brown <thom@linux.com> writes:
>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>> they'd kind of expect it near the drop of the CREATE list, but it's
>> actually toward the bottom. It just looks random at the moment.
>
> I did M-x sort-lines in the documentation. Still have to add entries
> for the new catalog though.
>
>>> test=# CREATE TABLE badname (id int, a int, b text);
>>> ERROR: invalid relation name: badname
>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>> SELECT 1
>>>
>>> This doesn't even get picked up by ANY COMMAND.
>
> I think Andres should add an entry for his patch on the commitfest. Is
> it ok?
I'll try Andres' patch this weekend while I test yours.
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> FWIW, I agree with Thom on this. If we do it as you suggest, I
>> confidently predict that it will be less than a year before we seriously
>> regret it. Given all the discussion around this, it's borderline insane
>> to believe that the set of parameters to be passed to command triggers
>> is nailed down and won't need to change in the future.
>
> That too will need to wait for the next revision, it's just about
> finding enough cycles, which is definitely happening very soon.
Could you give your thoughts on the design?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-03 00:08 ` Thom Brown <thom@linux.com>
2012-03-03 00:39 ` Re: Command Triggers, patch v11 anarazel@anarazel.de <andres@anarazel.de>
2012-03-03 00:56 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 3 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-03 00:08 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 2 March 2012 23:33, Thom Brown <thom@linux.com> wrote:
> On 2 March 2012 22:32, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>> test=# CREATE TABLE badname (id int, a int, b text);
>>>> ERROR: invalid relation name: badname
>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>>> SELECT 1
>>>>
>>>> This doesn't even get picked up by ANY COMMAND.
>>
>> I think Andres should add an entry for his patch on the commitfest. Is
>> it ok?
>
> I'll try Andres' patch this weekend while I test yours.
Actually no matter which patch I apply first, they cause the other to
fail to apply.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-03 00:39 ` anarazel@anarazel.de <andres@anarazel.de>
2 siblings, 0 replies; 115+ messages in thread
From: anarazel@anarazel.de @ 2012-03-03 00:39 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; pgsql-hackers
"anarazel@anarazel.de" <andres@anarazel.de> schrieb:
>
>
>Thom Brown <thom@linux.com> schrieb:
>
>>On 2 March 2012 23:33, Thom Brown <thom@linux.com> wrote:
>>> On 2 March 2012 22:32, Dimitri Fontaine <dimitri@2ndquadrant.fr>
>>wrote:
>>>>>> test=# CREATE TABLE badname (id int, a int, b text);
>>>>>> ERROR: invalid relation name: badname
>>>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a,
>>''::text b;
>>>>>> SELECT 1
>>>>>>
>>>>>> This doesn't even get picked up by ANY COMMAND.
>>>>
>>>> I think Andres should add an entry for his patch on the commitfest.
>> Is
>>>> it ok?
>>>
>>> I'll try Andres' patch this weekend while I test yours.
>>
>>Actually no matter which patch I apply first, they cause the other to
>>fail to apply.
>I will try to fix that on the plain tomorrow (to NYC) but I am not yet
>sure when/where I will have internet access again.
One more try: To the list.
Andres
Please excuse the brevity and formatting - I am writing this on my mobile phone.
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-03 00:56 ` Thom Brown <thom@linux.com>
2012-03-03 14:26 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-03 00:56 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 3 March 2012 00:08, Thom Brown <thom@linux.com> wrote:
> On 2 March 2012 23:33, Thom Brown <thom@linux.com> wrote:
>> On 2 March 2012 22:32, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>> test=# CREATE TABLE badname (id int, a int, b text);
>>>>> ERROR: invalid relation name: badname
>>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>>>> SELECT 1
>>>>>
>>>>> This doesn't even get picked up by ANY COMMAND.
>>>
>>> I think Andres should add an entry for his patch on the commitfest. Is
>>> it ok?
>>
>> I'll try Andres' patch this weekend while I test yours.
>
> Actually no matter which patch I apply first, they cause the other to
> fail to apply.
And having tried building it, it appears to fail.
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -g -I../../../src/include
-D_GNU_SOURCE -I/usr/include/libxml2 -c -o alter.o alter.c -MMD -MP
-MF .deps/alter.Po
alter.c: In function ‘ExecRenameStmt’:
alter.c:69:4: warning: passing argument 1 of ‘RenameCmdTrigger’ from
incompatible pointer type [enabled by default]
../../../src/include/commands/cmdtrigger.h:45:13: note: expected
‘const char *’ but argument is of type ‘struct List *’
alter.c:69:4: error: too many arguments to function ‘RenameCmdTrigger’
../../../src/include/commands/cmdtrigger.h:45:13: note: declared here
You've changed the signature of RenameCmdTrigger but still pass in the
old arguments in alter.c. If I fix this locally, I then get:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -fexcess-precision=standard -g -I../../../src/include
-D_GNU_SOURCE -I/usr/include/libxml2 -c -o copyfuncs.o copyfuncs.c
-MMD -MP -MF .deps/copyfuncs.Po
copyfuncs.c: In function ‘_copyAlterCmdTrigStmt’:
copyfuncs.c:3479:2: error: ‘AlterCmdTrigStmt’ has no member named ‘command’
copyfuncs.c:3479:2: error: ‘AlterCmdTrigStmt’ has no member named ‘command’
copyfuncs.c:3479:2: error: ‘AlterCmdTrigStmt’ has no member named ‘command’
There's an erroneous "COPY_STRING_FIELD(command)" in there, as well as
in equalfuncs.c. After removing both those instances it builds.
Are you sure you don't have any uncommitted changes?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:56 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-03 14:26 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 15:37 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-03 14:26 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> And having tried building it, it appears to fail.
Sorry about that, my compiler here was happy building the source (and I
had been doing make clean install along the way) and make installcheck
passed, here.
Now fixed on my github's branch, including docs.
I'll send an updated patch revision later, hopefully including pg_dump
support fixtures (well, adaptation to the new way of doing things IIUC)
and maybe with some trigger arguments rework done.
I understand that you're not blocked until that new version is out,
right? You could use either the incremental patch attached for
convenience.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
fix-rename-cmdtrigger.patch (text/x-patch, 8.7K) download
commit 301d8e58b6bfe89f35d82ad7a5216891f56c5d48
Author: Dimitri Fontaine <dim@tapoueh.org>
Date: Sat Mar 3 15:18:59 2012 +0100
Fix RenameCmdTrigger(), per review.
diff --git a/doc/src/sgml/ref/alter_command_trigger.sgml b/doc/src/sgml/ref/alter_command_trigger.sgml
index dd903e7..48b536c 100644
--- a/doc/src/sgml/ref/alter_command_trigger.sgml
+++ b/doc/src/sgml/ref/alter_command_trigger.sgml
@@ -22,6 +22,7 @@ PostgreSQL documentation
<refsynopsisdiv>
<synopsis>
ALTER COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> SET <replaceable class="parameter">enabled</replaceable>
+ALTER COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> RENAME TO <replaceable class="PARAMETER">newname</replaceable>
<phrase>where <replaceable class="parameter">enabled</replaceable> can be one of:</phrase>
@@ -62,10 +63,10 @@ ALTER COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> SET <rep
</varlistentry>
<varlistentry>
- <term><replaceable class="PARAMETER">command</replaceable></term>
+ <term><replaceable class="PARAMETER">newname</replaceable></term>
<listitem>
<para>
- The command tag on which this trigger acts.
+ The new name of the command trigger.
</para>
</listitem>
</varlistentry>
diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c
index 4d07642..b447306 100644
--- a/src/backend/commands/alter.c
+++ b/src/backend/commands/alter.c
@@ -66,7 +66,7 @@ ExecRenameStmt(RenameStmt *stmt)
break;
case OBJECT_CMDTRIGGER:
- RenameCmdTrigger(stmt->object, stmt->subname, stmt->newname);
+ RenameCmdTrigger(stmt->object, stmt->newname);
break;
case OBJECT_DATABASE:
diff --git a/src/backend/commands/cmdtrigger.c b/src/backend/commands/cmdtrigger.c
index e8d294d..ef9794f 100644
--- a/src/backend/commands/cmdtrigger.c
+++ b/src/backend/commands/cmdtrigger.c
@@ -294,13 +294,17 @@ AlterCmdTrigger(AlterCmdTrigStmt *stmt)
* Rename command trigger
*/
void
-RenameCmdTrigger(const char *trigname, const char *newname)
+RenameCmdTrigger(List *name, const char *newname)
{
SysScanDesc tgscan;
ScanKeyData skey[1];
HeapTuple tup;
Relation rel;
Form_pg_cmdtrigger cmdForm;
+ char *trigname;
+
+ Assert(list_length(name) == 1);
+ trigname = strVal((Value *)linitial(name));
CheckCmdTriggerPrivileges();
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index defcdd1..6a20a6c 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -3463,7 +3463,6 @@ _copyCreateCmdTrigStmt(const CreateCmdTrigStmt *from)
{
CreateCmdTrigStmt *newnode = makeNode(CreateCmdTrigStmt);
- COPY_NODE_FIELD(command);
COPY_STRING_FIELD(trigname);
COPY_SCALAR_FIELD(timing);
COPY_NODE_FIELD(funcname);
@@ -3476,7 +3475,6 @@ _copyAlterCmdTrigStmt(const AlterCmdTrigStmt *from)
{
AlterCmdTrigStmt *newnode = makeNode(AlterCmdTrigStmt);
- COPY_STRING_FIELD(command);
COPY_STRING_FIELD(trigname);
COPY_STRING_FIELD(tgenabled);
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index 1ad31f0..137075a 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -1780,7 +1780,6 @@ _equalCreateTrigStmt(const CreateTrigStmt *a, const CreateTrigStmt *b)
static bool
_equalCreateCmdTrigStmt(const CreateCmdTrigStmt *a, const CreateCmdTrigStmt *b)
{
- COMPARE_NODE_FIELD(command);
COMPARE_STRING_FIELD(trigname);
COMPARE_SCALAR_FIELD(timing);
COMPARE_NODE_FIELD(funcname);
@@ -1791,7 +1790,6 @@ _equalCreateCmdTrigStmt(const CreateCmdTrigStmt *a, const CreateCmdTrigStmt *b)
static bool
_equalAlterCmdTrigStmt(const AlterCmdTrigStmt *a, const AlterCmdTrigStmt *b)
{
- COMPARE_STRING_FIELD(command);
COMPARE_STRING_FIELD(trigname);
COMPARE_STRING_FIELD(tgenabled);
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index e5a0d34..e9872d3 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -6931,13 +6931,12 @@ RenameStmt: ALTER AGGREGATE func_name aggr_args RENAME TO name
n->missing_ok = false;
$$ = (Node *)n;
}
- | ALTER TRIGGER name ON COMMAND trigger_command RENAME TO name
+ | ALTER COMMAND TRIGGER name RENAME TO name
{
RenameStmt *n = makeNode(RenameStmt);
n->renameType = OBJECT_CMDTRIGGER;
- n->object = list_make1(makeString($6));
- n->subname = $3;
- n->newname = $9;
+ n->object = list_make1(makeString($4));
+ n->newname = $7;
$$ = (Node *)n;
}
| ALTER ROLE RoleId RENAME TO RoleId
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 3c75cf3..69d6479 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -168,7 +168,6 @@ call_before_cmdtriggers(Node *parsetree, CommandContext cmd)
case T_AlterOwnerStmt:
case T_AlterSeqStmt:
case T_AlterTableStmt:
- case T_RenameStmt:
case T_CommentStmt:
case T_DefineStmt:
case T_CreateCastStmt:
@@ -224,8 +223,14 @@ call_before_cmdtriggers(Node *parsetree, CommandContext cmd)
ExecBeforeCommandTriggers(cmd);
return;
+ case T_RenameStmt:
+ if (((RenameStmt *) parsetree)->renameType != OBJECT_CMDTRIGGER)
+ if (CommandFiresTriggers(cmd))
+ ExecBeforeCommandTriggers(cmd);
+ return;
+
case T_DropStmt:
- if (((DropStmt *) cmd->parsetree)->removeType != OBJECT_CMDTRIGGER)
+ if (((DropStmt *) parsetree)->removeType != OBJECT_CMDTRIGGER)
if (CommandFiresTriggers(cmd))
ExecBeforeCommandTriggers(cmd);
return;
@@ -251,7 +256,6 @@ call_after_cmdtriggers(Node *parsetree, CommandContext cmd)
case T_AlterOwnerStmt:
case T_AlterSeqStmt:
case T_AlterTableStmt:
- case T_RenameStmt:
case T_CommentStmt:
case T_DefineStmt:
case T_CreateCastStmt:
@@ -310,8 +314,14 @@ call_after_cmdtriggers(Node *parsetree, CommandContext cmd)
ExecAfterCommandTriggers(cmd);
return;
+ case T_RenameStmt:
+ if (((RenameStmt *) parsetree)->renameType != OBJECT_CMDTRIGGER)
+ if (CommandFiresTriggers(cmd))
+ ExecAfterCommandTriggers(cmd);
+ return;
+
case T_DropStmt:
- if (((DropStmt *) cmd->parsetree)->removeType != OBJECT_CMDTRIGGER)
+ if (((DropStmt *) parsetree)->removeType != OBJECT_CMDTRIGGER)
if (CommandFiresAfterTriggers(cmd))
ExecAfterCommandTriggers(cmd);
return;
diff --git a/src/include/commands/cmdtrigger.h b/src/include/commands/cmdtrigger.h
index 01a6ca3..fae2bfc 100644
--- a/src/include/commands/cmdtrigger.h
+++ b/src/include/commands/cmdtrigger.h
@@ -42,7 +42,7 @@ extern void CreateCmdTrigger(CreateCmdTrigStmt *stmt, const char *queryString);
extern void RemoveCmdTriggerById(Oid ctrigOid);
extern Oid get_cmdtrigger_oid(const char *trigname, bool missing_ok);
extern void AlterCmdTrigger(AlterCmdTrigStmt *stmt);
-extern void RenameCmdTrigger(const char *trigname, const char *newname);
+extern void RenameCmdTrigger(List *name, const char *newname);
extern void InitCommandContext(CommandContext cmd, const Node *stmt, bool list_triggers);
extern bool ListCommandTriggers(CommandContext cmd);
diff --git a/src/test/regress/expected/cmdtriggers.out b/src/test/regress/expected/cmdtriggers.out
index 8cb1f78..85a8d38 100644
--- a/src/test/regress/expected/cmdtriggers.out
+++ b/src/test/regress/expected/cmdtriggers.out
@@ -21,9 +21,10 @@ begin
end;
$$;
create command trigger snitch_before before any command execute procedure any_snitch();
-create command trigger snitch_after after any command execute procedure any_snitch();
+create command trigger snitch_after_ after any command execute procedure any_snitch();
alter command trigger snitch_before set disable;
alter command trigger snitch_before set enable;
+alter command trigger snitch_after_ rename to snitch_after;
create command trigger snitch_create_table after create table execute procedure snitch();
create command trigger snitch_alter_table after alter table execute procedure snitch();
create command trigger snitch_drop_table after drop table execute procedure snitch();
diff --git a/src/test/regress/sql/cmdtriggers.sql b/src/test/regress/sql/cmdtriggers.sql
index 215da78..60d3be0 100644
--- a/src/test/regress/sql/cmdtriggers.sql
+++ b/src/test/regress/sql/cmdtriggers.sql
@@ -23,10 +23,11 @@ end;
$$;
create command trigger snitch_before before any command execute procedure any_snitch();
-create command trigger snitch_after after any command execute procedure any_snitch();
+create command trigger snitch_after_ after any command execute procedure any_snitch();
alter command trigger snitch_before set disable;
alter command trigger snitch_before set enable;
+alter command trigger snitch_after_ rename to snitch_after;
create command trigger snitch_create_table after create table execute procedure snitch();
create command trigger snitch_alter_table after alter table execute procedure snitch();
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:56 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 14:26 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-03 15:37 ` Thom Brown <thom@linux.com>
0 siblings, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-03 15:37 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
On 3 March 2012 14:26, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Thom Brown <thom@linux.com> writes:
>> And having tried building it, it appears to fail.
>
> Sorry about that, my compiler here was happy building the source (and I
> had been doing make clean install along the way) and make installcheck
> passed, here.
>
> Now fixed on my github's branch, including docs.
>
> I'll send an updated patch revision later, hopefully including pg_dump
> support fixtures (well, adaptation to the new way of doing things IIUC)
> and maybe with some trigger arguments rework done.
>
> I understand that you're not blocked until that new version is out,
> right? You could use either the incremental patch attached for
> convenience.
Thanks for the extra patch. Do you see any functional changes between
now and your next patch? If so, it doesn't make sense for me to test
anything yet.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-04 15:50 ` Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 2 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-04 15:50 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; Tom Lane <tgl@sss.pgh.pa.us>
Hi,
On Saturday, March 03, 2012 01:08:33 AM Thom Brown wrote:
> On 2 March 2012 23:33, Thom Brown <thom@linux.com> wrote:
> > On 2 March 2012 22:32, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> >>>> test=# CREATE TABLE badname (id int, a int, b text);
> >>>> ERROR: invalid relation name: badname
> >>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> >>>> SELECT 1
> >>>>
> >>>> This doesn't even get picked up by ANY COMMAND.
> >>
> >> I think Andres should add an entry for his patch on the commitfest. Is
> >> it ok?
> >
> > I'll try Andres' patch this weekend while I test yours.
>
> Actually no matter which patch I apply first, they cause the other to
> fail to apply.
Ok, I rebased my patch ontop of dim's current HEAD. There was only one trivial
conflict in tablecmds.h. I had written the patch independently of the command
triggers stuff because I though, and still do, that would make applying it
easier.
Attached are two versions of the patch, one based on command triggers and one
without. Both pass regression tests for me.
Andres
Attachments: download all (2 files, .tar.gz)
ctas-01.patch (text/x-patch, 76.7K) download
From a7259034845e8d3e0f2b9cd93121553580d64715 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Sun, 4 Mar 2012 16:45:01 +0100
Subject: [PATCH] Transform CREATE TABLE AS/SELECT INTO into a utility
statement
---
src/backend/commands/copy.c | 20 +-
src/backend/commands/prepare.c | 69 +----
src/backend/commands/tablecmds.c | 335 +++++++++++++++++++++
src/backend/commands/view.c | 20 +-
src/backend/executor/execMain.c | 441 ++--------------------------
src/backend/executor/execUtils.c | 2 -
src/backend/executor/functions.c | 4 +-
src/backend/executor/spi.c | 10 +-
src/backend/nodes/copyfuncs.c | 18 +-
src/backend/nodes/equalfuncs.c | 16 +-
src/backend/nodes/outfuncs.c | 4 +-
src/backend/nodes/readfuncs.c | 1 -
src/backend/optimizer/plan/planner.c | 1 -
src/backend/optimizer/plan/subselect.c | 1 -
src/backend/optimizer/prep/prepjointree.c | 6 +-
src/backend/optimizer/util/clauses.c | 4 +-
src/backend/parser/analyze.c | 113 +++++---
src/backend/parser/gram.y | 28 ++-
src/backend/parser/parse_clause.c | 21 +-
src/backend/parser/parse_cte.c | 21 +-
src/backend/parser/parse_expr.c | 21 +-
src/backend/parser/parser.c | 38 +++
src/backend/rewrite/rewriteDefine.c | 3 +-
src/backend/tcop/pquery.c | 13 +-
src/backend/tcop/utility.c | 46 ++--
src/include/access/htup.h | 2 +-
src/include/commands/prepare.h | 3 +
src/include/commands/tablecmds.h | 4 +
src/include/executor/executor.h | 5 +
src/include/nodes/execnodes.h | 9 +-
src/include/nodes/nodes.h | 1 +
src/include/nodes/parsenodes.h | 20 +-
src/include/nodes/plannodes.h | 2 -
src/pl/plpgsql/src/pl_exec.c | 27 +--
src/test/regress/expected/select_into.out | 19 ++
src/test/regress/expected/transactions.out | 2 +-
src/test/regress/sql/select_into.sql | 15 +
37 files changed, 720 insertions(+), 645 deletions(-)
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 110480f..a3c5b4b 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -1190,6 +1190,20 @@ BeginCopy(bool is_from,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY (SELECT) WITH OIDS is not supported")));
+
+ /* Query mustn't use INTO, either */
+ if(IsA(raw_query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)raw_query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("COPY (SELECT INTO) is not supported")));
+ }
+
/*
* Run parse analysis and rewrite. Note this also acquires sufficient
* locks on the source table(s).
@@ -1211,12 +1225,6 @@ BeginCopy(bool is_from,
Assert(query->commandType == CMD_SELECT);
Assert(query->utilityStmt == NULL);
- /* Query mustn't use INTO, either */
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("COPY (SELECT INTO) is not supported")));
-
/* plan the query */
plan = planner(query, 0, NULL);
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 4883abe..86e8cf9 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -43,8 +43,6 @@
static HTAB *prepared_queries = NULL;
static void InitQueryHashTable(void);
-static ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
- const char *queryString, EState *estate);
static Datum build_regtype_array(Oid *param_types, int num_params);
/*
@@ -177,6 +175,9 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
* EXECUTE, which we might need for error reporting while processing the
* parameter expressions. The query_string that we copy from the plan
* source is that of the original PREPARE.
+ *
+ * If you add additional things here you should check whether
+ * CreateTableAs also needs them.
*/
void
ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
@@ -222,51 +223,9 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
query_string = MemoryContextStrdup(PortalGetHeapMemory(portal),
entry->plansource->query_string);
- /*
- * For CREATE TABLE / AS EXECUTE, we must make a copy of the stored query
- * so that we can modify its destination (yech, but this has always been
- * ugly). For regular EXECUTE we can just use the cached query, since the
- * executor is read-only.
- */
- if (stmt->into)
- {
- MemoryContext oldContext;
- PlannedStmt *pstmt;
-
- /* Replan if needed, and increment plan refcount transiently */
- cplan = GetCachedPlan(entry->plansource, paramLI, true);
-
- /* Copy plan into portal's context, and modify */
- oldContext = MemoryContextSwitchTo(PortalGetHeapMemory(portal));
-
- plan_list = copyObject(cplan->stmt_list);
-
- if (list_length(plan_list) != 1)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt = (PlannedStmt *) linitial(plan_list);
- if (!IsA(pstmt, PlannedStmt) ||
- pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt->intoClause = copyObject(stmt->into);
-
- MemoryContextSwitchTo(oldContext);
-
- /* We no longer need the cached plan refcount ... */
- ReleaseCachedPlan(cplan, true);
- /* ... and we don't want the portal to depend on it, either */
- cplan = NULL;
- }
- else
- {
- /* Replan if needed, and increment plan refcount for portal */
- cplan = GetCachedPlan(entry->plansource, paramLI, false);
- plan_list = cplan->stmt_list;
- }
+ /* Replan if needed, and increment plan refcount for portal */
+ cplan = GetCachedPlan(entry->plansource, paramLI, false);
+ plan_list = cplan->stmt_list;
PortalDefineQuery(portal,
NULL,
@@ -302,7 +261,7 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
* CreateQueryDesc(), which allows the executor to make use of the parameters
* during query execution.
*/
-static ParamListInfo
+ParamListInfo
EvaluateParams(PreparedStatement *pstmt, List *params,
const char *queryString, EState *estate)
{
@@ -666,20 +625,6 @@ ExplainExecuteQuery(ExecuteStmt *execstmt, ExplainState *es,
if (IsA(pstmt, PlannedStmt))
{
- if (execstmt->into)
- {
- if (pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
-
- /* Copy the stmt so we can modify it */
- pstmt = copyObject(pstmt);
-
- pstmt->intoClause = execstmt->into;
- }
-
ExplainOnePlan(pstmt, es, query_string, paramLI);
}
else
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index cd4490a..9a67cf5 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -44,6 +44,7 @@
#include "commands/cluster.h"
#include "commands/comment.h"
#include "commands/defrem.h"
+#include "commands/prepare.h"
#include "commands/sequence.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
@@ -68,6 +69,7 @@
#include "parser/parser.h"
#include "rewrite/rewriteDefine.h"
#include "rewrite/rewriteHandler.h"
+#include "tcop/tcopprot.h"
#include "storage/bufmgr.h"
#include "storage/lmgr.h"
#include "storage/lock.h"
@@ -195,6 +197,18 @@ struct dropmsgstrings
const char *drophint_msg;
};
+/*
+ * Support structure for CTAS
+ */
+typedef struct
+{
+ DestReceiver pub; /* publicly-known function pointers */
+ EState *estate; /* EState we are working with */
+ Relation rel; /* Relation to write to */
+ int hi_options; /* heap_insert performance options */
+ BulkInsertState bistate; /* bulk insert state */
+} DR_intorel;
+
static const struct dropmsgstrings dropmsgstringarray[] = {
{RELKIND_RELATION,
ERRCODE_UNDEFINED_TABLE,
@@ -671,6 +685,235 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
return relationId;
}
+void
+CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest){
+ IntoClause *into = stmt->into;
+ Query *query;
+ List *rewritten;
+ PlannedStmt *plan;
+ QueryDesc *queryDesc;
+ Relation intoRelationDesc;
+ CreateStmt *create;
+ int natt;
+ Oid intoRelationId;
+ ListCell *lc;
+ int eflags = 0;
+ EState *param_estate = NULL;
+ CachedPlan *cplan = NULL;
+
+ Assert(IsA(stmt->query, Query));
+ query = (Query*)stmt->query;
+
+ /*
+ * Construct plans for the supported
+ */
+ if(query->commandType == CMD_SELECT){
+ rewritten = QueryRewrite((Query *) copyObject(stmt->query));
+
+ if(!rewritten)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to nothing");
+
+ if(list_length(rewritten) != 1)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to more than one query");
+
+ plan = pg_plan_query(lfirst(list_head(rewritten)), 0, params);
+ }
+ else if(query->commandType == CMD_UTILITY &&
+ IsA(query->utilityStmt, ExecuteStmt)){
+ /*
+ * We cannot easily share more infrastructure with prepare.c's
+ * ExecuteQuery because teaching it to return a started
+ * executor would amount to about the same amount of
+ * duplication as doing it here.
+ *
+ */
+ ExecuteStmt *stmt;
+ PreparedStatement *entry;
+ List *plan_list;
+ ParamListInfo paramLI = NULL;
+
+ Assert(IsA(query->utilityStmt, ExecuteStmt));
+ stmt = (ExecuteStmt*)(query->utilityStmt);
+
+ entry = FetchPreparedStatement(stmt->name, true);
+
+ /* Shouldn't find a non-fixed-result cached plan */
+ if (!entry->plansource->fixed_result)
+ elog(ERROR, "EXECUTE does not support variable-result cached plans");
+
+ /* Evaluate parameters, if any */
+ if (entry->plansource->num_params > 0)
+ {
+ param_estate = CreateExecutorState();
+ param_estate->es_param_list_info = params;
+ paramLI = EvaluateParams(entry, stmt->params,
+ queryString, param_estate);
+
+ }
+
+ cplan = GetCachedPlan(entry->plansource, paramLI, true);
+ plan_list = cplan->stmt_list;
+
+ if (list_length(plan_list) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ plan = (PlannedStmt *) linitial(plan_list);
+ if (!IsA(plan, PlannedStmt) ||
+ plan->commandType != CMD_SELECT ||
+ plan->utilityStmt != NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ queryString = pstrdup(entry->plansource->query_string);
+ }
+ else{
+ elog(ERROR, "unsupported command for CREATE TABLE AS");
+ abort();//silence compiler
+ }
+
+
+ /*
+ * Use a snapshot with an updated command ID to ensure this query sees
+ * results of any previously executed queries.
+ */
+ PushCopiedSnapshot(GetActiveSnapshot());
+ UpdateActiveSnapshotCommandId();
+
+ queryDesc = CreateQueryDesc(plan, queryString,
+ GetActiveSnapshot(), InvalidSnapshot,
+ CreateDestReceiver(DestIntoRel), params,
+ false);
+
+ /*
+ * We need to tell the executor whether it has to produce oids or
+ * not because it doesn't have enough information to do so itself
+ * as were not telling it that its inserting into a table (because
+ * that would be too complicated for now)
+ */
+ if(interpretOidsOption(into->options))
+ eflags |= EXEC_FLAG_FORCE_OIDS_ON;
+ else
+ eflags |= EXEC_FLAG_FORCE_OIDS_OFF;
+
+ /*
+ * call ExecutorStart to prepare the plan for execution. Only
+ * after this we have enough information to actually create a
+ * target relation
+ */
+ ExecutorStart(queryDesc, eflags);
+
+ /*
+ * create the target relation
+ */
+ create = makeNode(CreateStmt);
+ create->relation = into->rel;
+ create->options = into->options;
+ create->oncommit = into->onCommit;
+ create->tablespacename = into->tableSpaceName;
+
+ /*
+ * If a column name list was specified in CREATE TABLE AS,
+ * override the column names derived from the query. (Too few
+ * column names are OK, too many are not.)
+ */
+ if (list_length(into->colNames) > queryDesc->tupDesc->natts)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("CREATE TABLE AS specifies too many column names")));
+ lc = list_head(into->colNames);
+ for(natt = 0; natt < queryDesc->tupDesc->natts; natt++){
+ ColumnDef *col = makeNode(ColumnDef);
+ TypeName *type = makeNode(TypeName);
+
+ Form_pg_attribute attribute = queryDesc->tupDesc->attrs[natt];
+
+ if(!lc)
+ col->colname = NameStr(attribute->attname);
+ else{
+ col->colname = strVal(lfirst(lc));
+ lc = lnext(lc);
+ }
+
+ col->collOid = attribute->attcollation;
+
+ type->typeOid = attribute->atttypid;
+ type->typemod = attribute->atttypmod;
+ col->typeName= type;
+
+ /*
+ * We check the column type here because collOid=InvalidOid
+ * denotes an invalid oid for a collatable type in
+ * queryDesc->tupDesc but GetColumnDefCollation - which will
+ * be called by DefineRelation - defers the default collation
+ * out of that...
+ * XXX: A better solution would be welcome.
+ */
+ CheckAttributeType(col->colname, col->typeName->typeOid, col->collOid,
+ NULL, false);
+ create->tableElts = lappend(create->tableElts, col);
+ }
+
+ /*
+ * Actually create the target table
+ */
+ intoRelationId = DefineRelation(create, RELKIND_RELATION, InvalidOid);
+ intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
+
+
+ if(!into->skipData){
+ DR_intorel *myState = (DR_intorel *) queryDesc->dest;
+ /* setup the target of the DestIntoRel receiver */
+ myState->estate = queryDesc->estate;
+ myState->rel = intoRelationDesc;
+
+ /* run the plan */
+ ExecutorRun(queryDesc, ForwardScanDirection, 0L);
+
+ }
+
+ /*
+ * Check INSERT permission on the constructed table.
+ *
+ * XXX: It would arguable make sense to do this check only if
+ * into->skipData is true.
+ */
+ {
+ RangeTblEntry *rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = intoRelationId;
+ rte->relkind = RELKIND_RELATION;
+ rte->requiredPerms = ACL_INSERT;
+
+ for (natt = 1; natt <= intoRelationDesc->rd_att->natts; natt++)
+ rte->modifiedCols = bms_add_member(rte->modifiedCols,
+ natt - FirstLowInvalidHeapAttributeNumber);
+
+ ExecCheckRTPerms(list_make1(rte), true);
+ }
+
+ /* run cleanup too */
+ ExecutorFinish(queryDesc);
+ ExecutorEnd(queryDesc);
+
+ /* close rel, but keep lock until commit */
+ heap_close(intoRelationDesc, NoLock);
+
+ FreeQueryDesc(queryDesc);
+
+ if(cplan){
+ ReleaseCachedPlan(cplan, true);
+
+ if (param_estate)
+ FreeExecutorState(param_estate);
+ }
+
+ PopActiveSnapshot();
+}
+
/*
* Emit the right error or warning message for a "DROP" command issued on a
* non-existent relation
@@ -10238,3 +10481,95 @@ RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid, Oid oldrelid,
ReleaseSysCache(tuple);
}
+
+/*
+ * Support for SELECT INTO (aka CREATE TABLE AS)
+ *
+ * We implement SELECT INTO by diverting SELECT's normal output with
+ * a specialized DestReceiver type.
+ */
+
+/*
+ * intorel_startup --- executor startup
+ */
+static void
+intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ myState->bistate = GetBulkInsertState();
+ myState->hi_options = HEAP_INSERT_SKIP_FSM;
+ if (!XLogIsNeeded())
+ myState->hi_options |= HEAP_INSERT_SKIP_WAL;
+
+}
+
+/*
+ * intorel_receive --- receive one tuple
+ */
+static void
+intorel_receive(TupleTableSlot *slot, DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ HeapTuple tuple;
+
+ /*
+ * get the heap tuple out of the tuple table slot, making sure we have a
+ * writable copy
+ */
+ tuple = ExecMaterializeSlot(slot);
+
+ /*
+ * force assignment of new OID (see comments in ExecInsert)
+ */
+ if (myState->rel->rd_rel->relhasoids)
+ HeapTupleSetOid(tuple, InvalidOid);
+
+ heap_insert(myState->rel,
+ tuple,
+ myState->estate->es_output_cid,
+ myState->hi_options,
+ myState->bistate);
+
+ /* We know this is a newly created relation, so there are no indexes */
+}
+
+/*
+ * intorel_shutdown --- executor end
+ */
+static void
+intorel_shutdown(DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+
+ FreeBulkInsertState(myState->bistate);
+ if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
+ heap_sync(myState->rel);
+}
+
+/*
+ * intorel_destroy --- release DestReceiver object
+ */
+static void
+intorel_destroy(DestReceiver *self)
+{
+ pfree(self);
+}
+
+/*
+ * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
+ *
+ */
+DestReceiver *
+CreateIntoRelDestReceiver(void)
+{
+ DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
+
+ self->pub.receiveSlot = intorel_receive;
+ self->pub.rStartup = intorel_startup;
+ self->pub.rShutdown = intorel_shutdown;
+ self->pub.rDestroy = intorel_destroy;
+ self->pub.mydest = DestIntoRel;
+ /* private fields will be set on startup */
+
+ return (DestReceiver *) self;
+}
diff --git a/src/backend/commands/view.c b/src/backend/commands/view.c
index 99fb7db..93e523a 100644
--- a/src/backend/commands/view.c
+++ b/src/backend/commands/view.c
@@ -428,6 +428,22 @@ DefineView(ViewStmt *stmt, const char *queryString)
RangeVar *view;
/*
+ * We check for SELECT INTO before parse analysis because that
+ * would complain about the SELECT INTO without specific enough detail.
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("views must not contain SELECT INTO")));
+ }
+
+ /*
* Run parse analysis to convert the raw parse tree to a Query. Note this
* also acquires sufficient locks on the source table(s).
*
@@ -449,10 +465,6 @@ DefineView(ViewStmt *stmt, const char *queryString)
* DefineQueryRewrite(), but that function will complain about a bogus ON
* SELECT rule, and we'd rather the message complain about a view.
*/
- if (viewParse->intoClause != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("views must not contain SELECT INTO")));
if (viewParse->hasModifyingCTE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 36dcc8e..1979325 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -90,12 +90,6 @@ static char *ExecBuildSlotValueDescription(TupleTableSlot *slot,
int maxfieldlen);
static void EvalPlanQualStart(EPQState *epqstate, EState *parentestate,
Plan *planTree);
-static void OpenIntoRel(QueryDesc *queryDesc);
-static void CloseIntoRel(QueryDesc *queryDesc);
-static void intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo);
-static void intorel_receive(TupleTableSlot *slot, DestReceiver *self);
-static void intorel_shutdown(DestReceiver *self);
-static void intorel_destroy(DestReceiver *self);
/* end of local decls */
@@ -174,11 +168,10 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
case CMD_SELECT:
/*
- * SELECT INTO, SELECT FOR UPDATE/SHARE and modifying CTEs need to
+ * SELECT FOR UPDATE/SHARE and modifying CTEs need to
* mark tuples
*/
- if (queryDesc->plannedstmt->intoClause != NULL ||
- queryDesc->plannedstmt->rowMarks != NIL ||
+ if (queryDesc->plannedstmt->rowMarks != NIL ||
queryDesc->plannedstmt->hasModifyingCTE)
estate->es_output_cid = GetCurrentCommandId(true);
@@ -212,6 +205,13 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
estate->es_top_eflags = eflags;
estate->es_instrument = queryDesc->instrument_options;
+ if(eflags & EXEC_FLAG_FORCE_OIDS_ON)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_ON;
+ else if(eflags & EXEC_FLAG_FORCE_OIDS_OFF)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_OFF;
+ else
+ estate->es_force_oids = ESTATE_FORCE_OIDS_DEFAULT;
+
/*
* Initialize the plan state tree
*/
@@ -310,13 +310,6 @@ standard_ExecutorRun(QueryDesc *queryDesc,
(*dest->rStartup) (dest, operation, queryDesc->tupDesc);
/*
- * if it's CREATE TABLE AS ... WITH NO DATA, skip plan execution
- */
- if (estate->es_select_into &&
- queryDesc->plannedstmt->intoClause->skipData)
- direction = NoMovementScanDirection;
-
- /*
* run plan
*/
if (!ScanDirectionIsNoMovement(direction))
@@ -451,12 +444,6 @@ standard_ExecutorEnd(QueryDesc *queryDesc)
ExecEndPlan(queryDesc->planstate, estate);
- /*
- * Close the SELECT INTO relation if any
- */
- if (estate->es_select_into)
- CloseIntoRel(queryDesc);
-
/* do away with our snapshots */
UnregisterSnapshot(estate->es_snapshot);
UnregisterSnapshot(estate->es_crosscheck_snapshot);
@@ -706,15 +693,6 @@ ExecCheckXactReadOnly(PlannedStmt *plannedstmt)
{
ListCell *l;
- /*
- * CREATE TABLE AS or SELECT INTO?
- *
- * XXX should we allow this if the destination is temp? Considering that
- * it would still require catalog changes, probably not.
- */
- if (plannedstmt->intoClause != NULL)
- PreventCommandIfReadOnly(CreateCommandTag((Node *) plannedstmt));
-
/* Fail if write permissions are requested on any non-temp table */
foreach(l, plannedstmt->rtable)
{
@@ -864,18 +842,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
}
/*
- * Detect whether we're doing SELECT INTO. If so, set the es_into_oids
- * flag appropriately so that the plan tree will be initialized with the
- * correct tuple descriptors. (Other SELECT INTO stuff comes later.)
- */
- estate->es_select_into = false;
- if (operation == CMD_SELECT && plannedstmt->intoClause != NULL)
- {
- estate->es_select_into = true;
- estate->es_into_oids = interpretOidsOption(plannedstmt->intoClause->options);
- }
-
- /*
* Initialize the executor's tuple table to empty.
*/
estate->es_tupleTable = NIL;
@@ -926,9 +892,7 @@ InitPlan(QueryDesc *queryDesc, int eflags)
planstate = ExecInitNode(plan, estate, eflags);
/*
- * Get the tuple descriptor describing the type of tuples to return. (this
- * is especially important if we are creating a relation with "SELECT
- * INTO")
+ * Get the tuple descriptor describing the type of tuples to return.
*/
tupType = ExecGetResultType(planstate);
@@ -968,16 +932,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
queryDesc->tupDesc = tupType;
queryDesc->planstate = planstate;
-
- /*
- * If doing SELECT INTO, initialize the "into" relation. We must wait
- * till now so we have the "clean" result tuple type to create the new
- * table from.
- *
- * If EXPLAIN, skip creating the "into" relation.
- */
- if (estate->es_select_into && !(eflags & EXEC_FLAG_EXPLAIN_ONLY))
- OpenIntoRel(queryDesc);
}
/*
@@ -1230,7 +1184,7 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
/*
* ExecContextForcesOids
*
- * This is pretty grotty: when doing INSERT, UPDATE, or SELECT INTO,
+ * This is pretty grotty: when doing INSERT or UPDATE
* we need to ensure that result tuples have space for an OID iff they are
* going to be stored into a relation that has OIDs. In other contexts
* we are free to choose whether to leave space for OIDs in result tuples
@@ -1255,15 +1209,25 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
* the ModifyTable node, so ModifyTable has to set es_result_relation_info
* while initializing each subplan.
*
- * SELECT INTO is even uglier, because we don't have the INTO relation's
- * descriptor available when this code runs; we have to look aside at a
- * flag set by InitPlan().
+ * SELECT INTO is even uglier, because we don't have the INTO
+ * relation's descriptor available - because its only defined after
+ * the query started - when this code runs; we have to look aside at
+ * flags which is passed to ExecutorStart via eflags.
*/
bool
ExecContextForcesOids(PlanState *planstate, bool *hasoids)
{
ResultRelInfo *ri = planstate->state->es_result_relation_info;
+ if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_ON){
+ *hasoids = true;
+ return true;
+ }
+ else if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_OFF){
+ *hasoids = false;
+ return true;
+ }
+
if (ri != NULL)
{
Relation rel = ri->ri_RelationDesc;
@@ -1275,12 +1239,6 @@ ExecContextForcesOids(PlanState *planstate, bool *hasoids)
}
}
- if (planstate->state->es_select_into)
- {
- *hasoids = planstate->state->es_into_oids;
- return true;
- }
-
return false;
}
@@ -2290,8 +2248,7 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
estate->es_rowMarks = parentestate->es_rowMarks;
estate->es_top_eflags = parentestate->es_top_eflags;
estate->es_instrument = parentestate->es_instrument;
- estate->es_select_into = parentestate->es_select_into;
- estate->es_into_oids = parentestate->es_into_oids;
+
/* es_auxmodifytables must NOT be copied */
/*
@@ -2423,351 +2380,3 @@ EvalPlanQualEnd(EPQState *epqstate)
epqstate->planstate = NULL;
epqstate->origslot = NULL;
}
-
-
-/*
- * Support for SELECT INTO (a/k/a CREATE TABLE AS)
- *
- * We implement SELECT INTO by diverting SELECT's normal output with
- * a specialized DestReceiver type.
- */
-
-typedef struct
-{
- DestReceiver pub; /* publicly-known function pointers */
- EState *estate; /* EState we are working with */
- DestReceiver *origdest; /* QueryDesc's original receiver */
- Relation rel; /* Relation to write to */
- int hi_options; /* heap_insert performance options */
- BulkInsertState bistate; /* bulk insert state */
-} DR_intorel;
-
-/*
- * OpenIntoRel --- actually create the SELECT INTO target relation
- *
- * This also replaces QueryDesc->dest with the special DestReceiver for
- * SELECT INTO. We assume that the correct result tuple type has already
- * been placed in queryDesc->tupDesc.
- */
-static void
-OpenIntoRel(QueryDesc *queryDesc)
-{
- IntoClause *into = queryDesc->plannedstmt->intoClause;
- EState *estate = queryDesc->estate;
- TupleDesc intoTupDesc = queryDesc->tupDesc;
- Relation intoRelationDesc;
- char *intoName;
- Oid namespaceId;
- Oid tablespaceId;
- Datum reloptions;
- Oid intoRelationId;
- DR_intorel *myState;
- RangeTblEntry *rte;
- AttrNumber attnum;
- static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
-
- Assert(into);
-
- /*
- * XXX This code needs to be kept in sync with DefineRelation(). Maybe we
- * should try to use that function instead.
- */
-
- /*
- * Check consistency of arguments
- */
- if (into->onCommit != ONCOMMIT_NOOP
- && into->rel->relpersistence != RELPERSISTENCE_TEMP)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
- errmsg("ON COMMIT can only be used on temporary tables")));
-
- {
- AclResult aclresult;
- int i;
-
- for (i = 0; i < intoTupDesc->natts; i++)
- {
- Oid atttypid = intoTupDesc->attrs[i]->atttypid;
-
- aclresult = pg_type_aclcheck(atttypid, GetUserId(), ACL_USAGE);
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TYPE,
- format_type_be(atttypid));
- }
- }
-
- /*
- * If a column name list was specified in CREATE TABLE AS, override the
- * column names derived from the query. (Too few column names are OK, too
- * many are not.) It would probably be all right to scribble directly on
- * the query's result tupdesc, but let's be safe and make a copy.
- */
- if (into->colNames)
- {
- ListCell *lc;
-
- intoTupDesc = CreateTupleDescCopy(intoTupDesc);
- attnum = 1;
- foreach(lc, into->colNames)
- {
- char *colname = strVal(lfirst(lc));
-
- if (attnum > intoTupDesc->natts)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("CREATE TABLE AS specifies too many column names")));
- namestrcpy(&(intoTupDesc->attrs[attnum - 1]->attname), colname);
- attnum++;
- }
- }
-
- /*
- * Find namespace to create in, check its permissions, lock it against
- * concurrent drop, and mark into->rel as RELPERSISTENCE_TEMP if the
- * selected namespace is temporary.
- */
- intoName = into->rel->relname;
- namespaceId = RangeVarGetAndCheckCreationNamespace(into->rel, NoLock,
- NULL);
-
- /*
- * Security check: disallow creating temp tables from security-restricted
- * code. This is needed because calling code might not expect untrusted
- * tables to appear in pg_temp at the front of its search path.
- */
- if (into->rel->relpersistence == RELPERSISTENCE_TEMP
- && InSecurityRestrictedOperation())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("cannot create temporary table within security-restricted operation")));
-
- /*
- * Select tablespace to use. If not specified, use default tablespace
- * (which may in turn default to database's default).
- */
- if (into->tableSpaceName)
- {
- tablespaceId = get_tablespace_oid(into->tableSpaceName, false);
- }
- else
- {
- tablespaceId = GetDefaultTablespace(into->rel->relpersistence);
- /* note InvalidOid is OK in this case */
- }
-
- /* Check permissions except when using the database's default space */
- if (OidIsValid(tablespaceId) && tablespaceId != MyDatabaseTableSpace)
- {
- AclResult aclresult;
-
- aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(),
- ACL_CREATE);
-
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TABLESPACE,
- get_tablespace_name(tablespaceId));
- }
-
- /* Parse and validate any reloptions */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- NULL,
- validnsps,
- true,
- false);
- (void) heap_reloptions(RELKIND_RELATION, reloptions, true);
-
- /* Now we can actually create the new relation */
- intoRelationId = heap_create_with_catalog(intoName,
- namespaceId,
- tablespaceId,
- InvalidOid,
- InvalidOid,
- InvalidOid,
- GetUserId(),
- intoTupDesc,
- NIL,
- RELKIND_RELATION,
- into->rel->relpersistence,
- false,
- false,
- true,
- 0,
- into->onCommit,
- reloptions,
- true,
- allowSystemTableMods);
- Assert(intoRelationId != InvalidOid);
-
- /*
- * Advance command counter so that the newly-created relation's catalog
- * tuples will be visible to heap_open.
- */
- CommandCounterIncrement();
-
- /*
- * If necessary, create a TOAST table for the INTO relation. Note that
- * AlterTableCreateToastTable ends with CommandCounterIncrement(), so that
- * the TOAST table will be visible for insertion.
- */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- "toast",
- validnsps,
- true,
- false);
-
- (void) heap_reloptions(RELKIND_TOASTVALUE, reloptions, true);
-
- AlterTableCreateToastTable(intoRelationId, reloptions);
-
- /*
- * And open the constructed table for writing.
- */
- intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
-
- /*
- * Check INSERT permission on the constructed table.
- */
- rte = makeNode(RangeTblEntry);
- rte->rtekind = RTE_RELATION;
- rte->relid = intoRelationId;
- rte->relkind = RELKIND_RELATION;
- rte->requiredPerms = ACL_INSERT;
-
- for (attnum = 1; attnum <= intoTupDesc->natts; attnum++)
- rte->modifiedCols = bms_add_member(rte->modifiedCols,
- attnum - FirstLowInvalidHeapAttributeNumber);
-
- ExecCheckRTPerms(list_make1(rte), true);
-
- /*
- * Now replace the query's DestReceiver with one for SELECT INTO
- */
- myState = (DR_intorel *) CreateDestReceiver(DestIntoRel);
- Assert(myState->pub.mydest == DestIntoRel);
- myState->estate = estate;
- myState->origdest = queryDesc->dest;
- myState->rel = intoRelationDesc;
-
- queryDesc->dest = (DestReceiver *) myState;
-
- /*
- * We can skip WAL-logging the insertions, unless PITR or streaming
- * replication is in use. We can skip the FSM in any case.
- */
- myState->hi_options = HEAP_INSERT_SKIP_FSM |
- (XLogIsNeeded() ? 0 : HEAP_INSERT_SKIP_WAL);
- myState->bistate = GetBulkInsertState();
-
- /* Not using WAL requires smgr_targblock be initially invalid */
- Assert(RelationGetTargetBlock(intoRelationDesc) == InvalidBlockNumber);
-}
-
-/*
- * CloseIntoRel --- clean up SELECT INTO at ExecutorEnd time
- */
-static void
-CloseIntoRel(QueryDesc *queryDesc)
-{
- DR_intorel *myState = (DR_intorel *) queryDesc->dest;
-
- /*
- * OpenIntoRel might never have gotten called, and we also want to guard
- * against double destruction.
- */
- if (myState && myState->pub.mydest == DestIntoRel)
- {
- FreeBulkInsertState(myState->bistate);
-
- /* If we skipped using WAL, must heap_sync before commit */
- if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
- heap_sync(myState->rel);
-
- /* close rel, but keep lock until commit */
- heap_close(myState->rel, NoLock);
-
- /* restore the receiver belonging to executor's caller */
- queryDesc->dest = myState->origdest;
-
- /* might as well invoke my destructor */
- intorel_destroy((DestReceiver *) myState);
- }
-}
-
-/*
- * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
- */
-DestReceiver *
-CreateIntoRelDestReceiver(void)
-{
- DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
-
- self->pub.receiveSlot = intorel_receive;
- self->pub.rStartup = intorel_startup;
- self->pub.rShutdown = intorel_shutdown;
- self->pub.rDestroy = intorel_destroy;
- self->pub.mydest = DestIntoRel;
-
- /* private fields will be set by OpenIntoRel */
-
- return (DestReceiver *) self;
-}
-
-/*
- * intorel_startup --- executor startup
- */
-static void
-intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
-{
- /* no-op */
-}
-
-/*
- * intorel_receive --- receive one tuple
- */
-static void
-intorel_receive(TupleTableSlot *slot, DestReceiver *self)
-{
- DR_intorel *myState = (DR_intorel *) self;
- HeapTuple tuple;
-
- /*
- * get the heap tuple out of the tuple table slot, making sure we have a
- * writable copy
- */
- tuple = ExecMaterializeSlot(slot);
-
- /*
- * force assignment of new OID (see comments in ExecInsert)
- */
- if (myState->rel->rd_rel->relhasoids)
- HeapTupleSetOid(tuple, InvalidOid);
-
- heap_insert(myState->rel,
- tuple,
- myState->estate->es_output_cid,
- myState->hi_options,
- myState->bistate);
-
- /* We know this is a newly created relation, so there are no indexes */
-}
-
-/*
- * intorel_shutdown --- executor end
- */
-static void
-intorel_shutdown(DestReceiver *self)
-{
- /* no-op */
-}
-
-/*
- * intorel_destroy --- release DestReceiver object
- */
-static void
-intorel_destroy(DestReceiver *self)
-{
- pfree(self);
-}
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index 6db42e7..40cd5ce 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -137,8 +137,6 @@ CreateExecutorState(void)
estate->es_top_eflags = 0;
estate->es_instrument = 0;
- estate->es_select_into = false;
- estate->es_into_oids = false;
estate->es_finished = false;
estate->es_exprcontexts = NIL;
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index 61f4622..ae8d374 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -535,7 +535,6 @@ init_execution_state(List *queryTree_list,
if (ps->commandType == CMD_SELECT &&
ps->utilityStmt == NULL &&
- ps->intoClause == NULL &&
!ps->hasModifyingCTE)
fcache->lazyEval = lasttages->lazyEval = true;
}
@@ -1493,8 +1492,7 @@ check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,
*/
if (parse &&
parse->commandType == CMD_SELECT &&
- parse->utilityStmt == NULL &&
- parse->intoClause == NULL)
+ parse->utilityStmt == NULL)
{
tlist_ptr = &parse->targetList;
tlist = parse->targetList;
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index 81f284c..ce6abcf 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.c
@@ -1917,7 +1917,11 @@ _SPI_execute_plan(SPIPlanPtr plan, ParamListInfo paramLI,
if (_SPI_current->tuptable)
_SPI_current->processed = _SPI_current->tuptable->alloced -
_SPI_current->tuptable->free;
- res = SPI_OK_UTILITY;
+ if(nodeTag(stmt) == T_CreateTableAsStmt &&
+ ((CreateTableAsStmt*)stmt)->is_select_into)
+ res = SPI_OK_SELINTO;
+ else
+ res = SPI_OK_UTILITY;
}
/*
@@ -2042,9 +2046,7 @@ _SPI_pquery(QueryDesc *queryDesc, bool fire_triggers, long tcount)
{
case CMD_SELECT:
Assert(queryDesc->plannedstmt->utilityStmt == NULL);
- if (queryDesc->plannedstmt->intoClause) /* select into table? */
- res = SPI_OK_SELINTO;
- else if (queryDesc->dest->mydest != DestSPI)
+ if (queryDesc->dest->mydest != DestSPI)
{
/* Don't return SPI_OK_SELECT if we're discarding result */
res = SPI_OK_UTILITY;
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 7fec4db..e4f1815 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -85,7 +85,6 @@ _copyPlannedStmt(const PlannedStmt *from)
COPY_NODE_FIELD(rtable);
COPY_NODE_FIELD(resultRelations);
COPY_NODE_FIELD(utilityStmt);
- COPY_NODE_FIELD(intoClause);
COPY_NODE_FIELD(subplans);
COPY_BITMAPSET_FIELD(rewindPlanIDs);
COPY_NODE_FIELD(rowMarks);
@@ -2419,7 +2418,6 @@ _copyQuery(const Query *from)
COPY_SCALAR_FIELD(canSetTag);
COPY_NODE_FIELD(utilityStmt);
COPY_SCALAR_FIELD(resultRelation);
- COPY_NODE_FIELD(intoClause);
COPY_SCALAR_FIELD(hasAggs);
COPY_SCALAR_FIELD(hasWindowFuncs);
COPY_SCALAR_FIELD(hasSubLinks);
@@ -3207,6 +3205,18 @@ _copyExplainStmt(const ExplainStmt *from)
return newnode;
}
+static CreateTableAsStmt *
+_copyCreateTableAsStmt(CreateTableAsStmt *from)
+{
+ CreateTableAsStmt *newnode = makeNode(CreateTableAsStmt);
+
+ COPY_NODE_FIELD(query);
+ COPY_NODE_FIELD(into);
+ COPY_SCALAR_FIELD(is_select_into);
+
+ return newnode;
+}
+
static CreateSeqStmt *
_copyCreateSeqStmt(const CreateSeqStmt *from)
{
@@ -3615,7 +3625,6 @@ _copyExecuteStmt(const ExecuteStmt *from)
ExecuteStmt *newnode = makeNode(ExecuteStmt);
COPY_STRING_FIELD(name);
- COPY_NODE_FIELD(into);
COPY_NODE_FIELD(params);
return newnode;
@@ -4250,6 +4259,9 @@ copyObject(const void *from)
case T_ExplainStmt:
retval = _copyExplainStmt(from);
break;
+ case T_CreateTableAsStmt:
+ retval = _copyCreateTableAsStmt(from);
+ break;
case T_CreateSeqStmt:
retval = _copyCreateSeqStmt(from);
break;
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index d2a79eb..4ac895e 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -900,7 +900,6 @@ _equalQuery(const Query *a, const Query *b)
COMPARE_SCALAR_FIELD(canSetTag);
COMPARE_NODE_FIELD(utilityStmt);
COMPARE_SCALAR_FIELD(resultRelation);
- COMPARE_NODE_FIELD(intoClause);
COMPARE_SCALAR_FIELD(hasAggs);
COMPARE_SCALAR_FIELD(hasWindowFuncs);
COMPARE_SCALAR_FIELD(hasSubLinks);
@@ -1564,6 +1563,17 @@ _equalExplainStmt(const ExplainStmt *a, const ExplainStmt *b)
return true;
}
+
+static bool
+_equalCreateTableAsStmt(CreateTableAsStmt *a, CreateTableAsStmt *b)
+{
+ COMPARE_NODE_FIELD(query);
+ COMPARE_NODE_FIELD(into);
+ COMPARE_SCALAR_FIELD(is_select_into);
+
+ return true;
+}
+
static bool
_equalCreateSeqStmt(const CreateSeqStmt *a, const CreateSeqStmt *b)
{
@@ -1908,7 +1918,6 @@ static bool
_equalExecuteStmt(const ExecuteStmt *a, const ExecuteStmt *b)
{
COMPARE_STRING_FIELD(name);
- COMPARE_NODE_FIELD(into);
COMPARE_NODE_FIELD(params);
return true;
@@ -2793,6 +2802,9 @@ equal(const void *a, const void *b)
case T_ExplainStmt:
retval = _equalExplainStmt(a, b);
break;
+ case T_CreateTableAsStmt:
+ retval = _equalCreateTableAsStmt(a, b);
+ break;
case T_CreateSeqStmt:
retval = _equalCreateSeqStmt(a, b);
break;
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index 25a215e..9cb8592 100644
--- a/src/backend/nodes/outfuncs.c
+++ b/src/backend/nodes/outfuncs.c
@@ -248,7 +248,6 @@ _outPlannedStmt(StringInfo str, const PlannedStmt *node)
WRITE_NODE_FIELD(rtable);
WRITE_NODE_FIELD(resultRelations);
WRITE_NODE_FIELD(utilityStmt);
- WRITE_NODE_FIELD(intoClause);
WRITE_NODE_FIELD(subplans);
WRITE_BITMAPSET_FIELD(rewindPlanIDs);
WRITE_NODE_FIELD(rowMarks);
@@ -2187,7 +2186,6 @@ _outQuery(StringInfo str, const Query *node)
appendStringInfo(str, " :utilityStmt <>");
WRITE_INT_FIELD(resultRelation);
- WRITE_NODE_FIELD(intoClause);
WRITE_BOOL_FIELD(hasAggs);
WRITE_BOOL_FIELD(hasWindowFuncs);
WRITE_BOOL_FIELD(hasSubLinks);
@@ -2805,7 +2803,7 @@ _outNode(StringInfo str, const void *obj)
case T_RangeVar:
_outRangeVar(str, obj);
break;
- case T_IntoClause:
+ case T_IntoClause:/*XXX: This could be removed but dim would need to add it right back*/
_outIntoClause(str, obj);
break;
case T_Var:
diff --git a/src/backend/nodes/readfuncs.c b/src/backend/nodes/readfuncs.c
index b9258ad..9b57956 100644
--- a/src/backend/nodes/readfuncs.c
+++ b/src/backend/nodes/readfuncs.c
@@ -198,7 +198,6 @@ _readQuery(void)
READ_BOOL_FIELD(canSetTag);
READ_NODE_FIELD(utilityStmt);
READ_INT_FIELD(resultRelation);
- READ_NODE_FIELD(intoClause);
READ_BOOL_FIELD(hasAggs);
READ_BOOL_FIELD(hasWindowFuncs);
READ_BOOL_FIELD(hasSubLinks);
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 8bbe977..6b0541b 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -233,7 +233,6 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->rtable = glob->finalrtable;
result->resultRelations = glob->resultRelations;
result->utilityStmt = parse->utilityStmt;
- result->intoClause = parse->intoClause;
result->subplans = glob->subplans;
result->rewindPlanIDs = glob->rewindPlanIDs;
result->rowMarks = glob->finalrowmarks;
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 40a420a..8006787 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -1399,7 +1399,6 @@ simplify_EXISTS_query(Query *query)
* are complex.
*/
if (query->commandType != CMD_SELECT ||
- query->intoClause ||
query->setOperations ||
query->hasAggs ||
query->hasWindowFuncs ||
diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
index 59a5268..0304c9d 100644
--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -1129,8 +1129,7 @@ is_simple_subquery(Query *subquery)
*/
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/*
@@ -1216,8 +1215,7 @@ is_simple_union_all(Query *subquery)
/* Let's just make sure it's a valid subselect ... */
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/* Is it a set-operation query at all? */
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index cd3da46..7d40e3e 100644
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -4168,7 +4168,6 @@ inline_function(Oid funcid, Oid result_type, Oid result_collid,
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
querytree->utilityStmt ||
- querytree->intoClause ||
querytree->hasAggs ||
querytree->hasWindowFuncs ||
querytree->hasSubLinks ||
@@ -4682,8 +4681,7 @@ inline_set_returning_function(PlannerInfo *root, RangeTblEntry *rte)
*/
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
- querytree->utilityStmt ||
- querytree->intoClause)
+ querytree->utilityStmt)
goto fail;
/*
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index b187b03..182d6f7 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -62,6 +62,8 @@ static Query *transformDeclareCursorStmt(ParseState *pstate,
DeclareCursorStmt *stmt);
static Query *transformExplainStmt(ParseState *pstate,
ExplainStmt *stmt);
+static Query *transformCreateTableAsStmt(ParseState *pstate,
+ CreateTableAsStmt *stmt);
static void transformLockingClause(ParseState *pstate, Query *qry,
LockingClause *lc, bool pushedDown);
@@ -202,6 +204,11 @@ transformStmt(ParseState *pstate, Node *parseTree)
(ExplainStmt *) parseTree);
break;
+ case T_CreateTableAsStmt:
+ result = transformCreateTableAsStmt(pstate,
+ (CreateTableAsStmt *) parseTree);
+ break;
+
default:
/*
@@ -257,6 +264,7 @@ analyze_requires_snapshot(Node *parseTree)
result = true;
break;
+ case T_CreateTableAsStmt:
case T_ExplainStmt:
/* yes, because we must analyze the contained statement */
result = true;
@@ -455,21 +463,29 @@ transformInsertStmt(ParseState *pstate, InsertStmt *stmt)
sub_pstate->p_relnamespace = sub_relnamespace;
sub_pstate->p_varnamespace = sub_varnamespace;
+ /* The grammar should have produced a SELECT, but it might have INTO */
+ if(IsA(stmt->selectStmt, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->selectStmt;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INSERT ... SELECT cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
selectQuery = transformStmt(sub_pstate, stmt->selectStmt);
free_parsestate(sub_pstate);
- /* The grammar should have produced a SELECT, but it might have INTO */
if (!IsA(selectQuery, Query) ||
selectQuery->commandType != CMD_SELECT ||
selectQuery->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in INSERT ... SELECT");
- if (selectQuery->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("INSERT ... SELECT cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) selectQuery->intoClause))));
/*
* Make the source be a subquery in the INSERT's rangetable, and add
@@ -876,6 +892,18 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
Node *qual;
ListCell *l;
+ /*
+ * Validity-check whether we got called from somewhere where
+ * ... INTO was not allowed
+ */
+ if (stmt->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INTO is only allowed on first SELECT of UNION/INTERSECT/EXCEPT"),
+ parser_errposition(pstate,
+ exprLocation((Node *) stmt->intoClause))));
+
+
qry->commandType = CMD_SELECT;
/* process the WITH clause independently of all else */
@@ -963,8 +991,6 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
pstate->p_windowdefs,
&qry->targetList);
- /* SELECT INTO/CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
qry->rtable = pstate->p_rtable;
qry->jointree = makeFromExpr(pstate->p_joinlist, qual);
@@ -1185,9 +1211,6 @@ transformValuesClause(ParseState *pstate, SelectStmt *stmt)
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("SELECT FOR UPDATE/SHARE cannot be applied to VALUES")));
- /* CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
-
/*
* There mustn't have been any table references in the expressions, else
* strange things would happen, like Cartesian products of those tables
@@ -1253,7 +1276,6 @@ static Query *
transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
{
Query *qry = makeNode(Query);
- SelectStmt *leftmostSelect;
int leftmostRTI;
Query *leftmostQuery;
SetOperationStmt *sostmt;
@@ -1286,20 +1308,6 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
}
/*
- * Find leftmost leaf SelectStmt; extract the one-time-only items from it
- * and from the top-level node.
- */
- leftmostSelect = stmt->larg;
- while (leftmostSelect && leftmostSelect->op != SETOP_NONE)
- leftmostSelect = leftmostSelect->larg;
- Assert(leftmostSelect && IsA(leftmostSelect, SelectStmt) &&
- leftmostSelect->larg == NULL);
- qry->intoClause = leftmostSelect->intoClause;
-
- /* clear this to prevent complaints in transformSetOperationTree() */
- leftmostSelect->intoClause = NULL;
-
- /*
* These are not one-time, exactly, but we want to process them here and
* not let transformSetOperationTree() see them --- else it'll just
* recurse right back here!
@@ -1330,7 +1338,7 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
qry->setOperations = (Node *) sostmt;
/*
- * Re-find leftmost SELECT (now it's a sub-query in rangetable)
+ * Find leftmost SELECT (it's a sub-query in rangetable)
*/
node = sostmt->larg;
while (node && IsA(node, SetOperationStmt))
@@ -2099,6 +2107,25 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
(errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
errmsg("cannot specify both SCROLL and NO SCROLL")));
+ /*
+ * We must explicitly disallow DECLARE CURSOR ... SELECT INTO We
+ * have to do this before transformStmt() as that will holler if
+ * it ever finds a intoClause
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
+ errmsg("DECLARE CURSOR cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
result = transformStmt(pstate, stmt->query);
/* Grammar should not have allowed anything but SELECT */
@@ -2107,14 +2134,6 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
result->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in DECLARE CURSOR");
- /* But we must explicitly disallow DECLARE CURSOR ... SELECT INTO */
- if (result->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
- errmsg("DECLARE CURSOR cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) result->intoClause))));
-
/*
* We also disallow data-modifying WITH in a cursor. (This could be
* allowed, but the semantics of when the updates occur might be
@@ -2183,6 +2202,28 @@ transformExplainStmt(ParseState *pstate, ExplainStmt *stmt)
/*
+ * transformCreateTableAsStmt -
+ * transform an CREATE TABLE AS/SELECT ... INTO Statement
+ *
+ */
+static Query *
+transformCreateTableAsStmt(ParseState *pstate, CreateTableAsStmt *stmt)
+{
+ Query *result;
+
+ /* transform contained query */
+ stmt->query = (Node *) transformStmt(pstate, stmt->query);
+
+ /* represent the command as a utility Query */
+ result = makeNode(Query);
+ result->commandType = CMD_UTILITY;
+ result->utilityStmt = (Node *) stmt;
+
+ return result;
+}
+
+
+/*
* Check for features that are not supported together with FOR UPDATE/SHARE.
*
* exported so planner can check again after rewriting, query pullup, etc
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 9aea2cd..962074c 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -3052,23 +3052,28 @@ ExistingIndex: USING INDEX index_name { $$ = $3; }
CreateAsStmt:
CREATE OptTemp TABLE create_as_target AS SelectStmt opt_with_data
{
+ SelectStmt *n;
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = $4;
+ ctas->query = $6;
+ ctas->is_select_into = false;
+ $4->skipData = !($7);
+ $4->rel->relpersistence = $2;
+ $4->skipData = !($7);
+ $$ = (Node*)ctas;
+
/*
* When the SelectStmt is a set-operation tree, we must
* stuff the INTO information into the leftmost component
* Select, because that's where analyze.c will expect
* to find it.
*/
- SelectStmt *n = findLeftmostSelect((SelectStmt *) $6);
+ n = findLeftmostSelect((SelectStmt *) $6);
if (n->intoClause != NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("CREATE TABLE AS cannot specify INTO"),
parser_errposition(exprLocation((Node *) n->intoClause))));
- n->intoClause = $4;
- /* cram additional flags into the IntoClause */
- $4->rel->relpersistence = $2;
- $4->skipData = !($7);
- $$ = $6;
}
;
@@ -8275,20 +8280,25 @@ ExecuteStmt: EXECUTE name execute_param_clause
ExecuteStmt *n = makeNode(ExecuteStmt);
n->name = $2;
n->params = $3;
- n->into = NULL;
$$ = (Node *) n;
}
| CREATE OptTemp TABLE create_as_target AS
EXECUTE name execute_param_clause opt_with_data
{
ExecuteStmt *n = makeNode(ExecuteStmt);
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+
n->name = $7;
n->params = $8;
- n->into = $4;
+
/* cram additional flags into the IntoClause */
$4->rel->relpersistence = $2;
$4->skipData = !($9);
- $$ = (Node *) n;
+
+ ctas->into = $4;
+ ctas->query = (Node*)n;
+ ctas->is_select_into = false;
+ $$ = (Node *) ctas;
}
;
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 7f4da92..52f449f 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -481,6 +481,21 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
if (r->alias == NULL)
elog(ERROR, "subquery in FROM must have an alias");
+
+ if(IsA(r->subquery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)r->subquery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in FROM cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
/*
* Analyze and transform the subquery.
*/
@@ -495,12 +510,6 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
query->commandType != CMD_SELECT ||
query->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in subquery in FROM");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in FROM cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
/*
* The subquery cannot make use of any variables from FROM items created
diff --git a/src/backend/parser/parse_cte.c b/src/backend/parser/parse_cte.c
index c0c6240..4ea8ee6 100644
--- a/src/backend/parser/parse_cte.c
+++ b/src/backend/parser/parse_cte.c
@@ -241,6 +241,20 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
/* Analysis not done already */
Assert(!IsA(cte->ctequery, Query));
+ if(IsA(cte->ctequery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)cte->ctequery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in WITH cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
query = parse_sub_analyze(cte->ctequery, pstate, cte, false);
cte->ctequery = (Node *) query;
@@ -253,13 +267,6 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
if (query->utilityStmt != NULL)
elog(ERROR, "unexpected utility statement in WITH");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in WITH cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
-
/*
* We disallow data-modifying WITH except at the top level of a query,
* because it's not clear when such a modification should be executed.
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index d22d8a1..d4d9121 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1398,6 +1398,21 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
return result;
pstate->p_hasSubLinks = true;
+
+ if(IsA(sublink->subselect, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)sublink->subselect;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
qtree = parse_sub_analyze(sublink->subselect, pstate, NULL, false);
/*
@@ -1408,12 +1423,6 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
qtree->commandType != CMD_SELECT ||
qtree->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in SubLink");
- if (qtree->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) qtree->intoClause))));
sublink->subselect = (Node *) qtree;
diff --git a/src/backend/parser/parser.c b/src/backend/parser/parser.c
index f9ec2b2..854925c 100644
--- a/src/backend/parser/parser.c
+++ b/src/backend/parser/parser.c
@@ -37,6 +37,7 @@ raw_parser(const char *str)
core_yyscan_t yyscanner;
base_yy_extra_type yyextra;
int yyresult;
+ ListCell *c;
/* initialize the flex scanner */
yyscanner = scanner_init(str, &yyextra.core_yy_extra,
@@ -57,6 +58,43 @@ raw_parser(const char *str)
if (yyresult) /* error */
return NIL;
+ /*
+ * Some things are rather hard to properly diagnose in grammar
+ * without complicating/duplicating it too much. So we do some
+ * postprocessing here.
+ */
+ foreach(c, yyextra.parsetree){
+ switch(nodeTag(lfirst(c))){
+ /*
+ * The grammar currently doesn't disambiguate between
+ * SELECT and SELECT ... INTO. Do that now.
+ */
+ case T_SelectStmt:
+ {
+ SelectStmt* s = (SelectStmt*)lfirst(c);
+ SelectStmt* first = s;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+ Assert(first && IsA(first, SelectStmt) && first->larg == NULL);
+ if(first->intoClause){
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = first->intoClause;
+ ctas->query = (Node*)s;
+ ctas->is_select_into = true;
+ /*
+ * this way everyone can complain if this is set
+ * without further checks because it shall never
+ * be set but here.
+ */
+ first->intoClause = NULL;
+ lfirst(c) = ctas;
+ break;
+ }
+ }
+ default:
+ break;
+ }
+ }
return yyextra.parsetree;
}
diff --git a/src/backend/rewrite/rewriteDefine.c b/src/backend/rewrite/rewriteDefine.c
index 8c87ac5..24199e8 100644
--- a/src/backend/rewrite/rewriteDefine.c
+++ b/src/backend/rewrite/rewriteDefine.c
@@ -323,8 +323,7 @@ DefineQueryRewrite(char *rulename,
query = (Query *) linitial(action);
if (!is_instead ||
query->commandType != CMD_SELECT ||
- query->utilityStmt != NULL ||
- query->intoClause != NULL)
+ query->utilityStmt != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("rules on SELECT must have action INSTEAD SELECT")));
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 42a0fb0..7c50284 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -260,8 +260,7 @@ ChoosePortalStrategy(List *stmts)
if (query->canSetTag)
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
{
if (query->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -285,8 +284,7 @@ ChoosePortalStrategy(List *stmts)
if (pstmt->canSetTag)
{
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
{
if (pstmt->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -395,8 +393,7 @@ FetchStatementTargetList(Node *stmt)
else
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
return query->targetList;
if (query->returningList)
return query->returningList;
@@ -408,8 +405,7 @@ FetchStatementTargetList(Node *stmt)
PlannedStmt *pstmt = (PlannedStmt *) stmt;
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
return pstmt->planTree->targetlist;
if (pstmt->hasReturning)
return pstmt->planTree->targetlist;
@@ -430,7 +426,6 @@ FetchStatementTargetList(Node *stmt)
ExecuteStmt *estmt = (ExecuteStmt *) stmt;
PreparedStatement *entry;
- Assert(!estmt->into);
entry = FetchPreparedStatement(estmt->name, true);
return FetchPreparedStatementTargetList(entry);
}
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 5b81c0b..35ccdb3 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -127,9 +127,7 @@ CommandIsReadOnly(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- return false; /* SELECT INTO */
- else if (stmt->rowMarks != NIL)
+ if (stmt->rowMarks != NIL)
return false; /* SELECT FOR UPDATE/SHARE */
else if (stmt->hasModifyingCTE)
return false; /* data-modifying CTE */
@@ -198,6 +196,7 @@ check_xact_readonly(Node *parsetree)
case T_CreateSchemaStmt:
case T_CreateSeqStmt:
case T_CreateStmt:
+ case T_CreateTableAsStmt:
case T_CreateTableSpaceStmt:
case T_CreateTrigStmt:
case T_CompositeTypeStmt:
@@ -1036,6 +1035,10 @@ standard_ProcessUtility(Node *parsetree,
ExplainQuery((ExplainStmt *) parsetree, queryString, params, dest);
break;
+ case T_CreateTableAsStmt:
+ CreateTableAs((CreateTableAsStmt *) parsetree, queryString, params, dest);
+ break;
+
case T_VariableSetStmt:
ExecSetVariableStmt((VariableSetStmt *) parsetree);
break;
@@ -1230,8 +1233,6 @@ UtilityReturnsTuples(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return false;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return false; /* not our business to raise error */
@@ -1282,8 +1283,6 @@ UtilityTupleDescriptor(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return NULL;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return NULL; /* not our business to raise error */
@@ -1318,8 +1317,7 @@ QueryReturnsTuples(Query *parsetree)
{
case CMD_SELECT:
/* returns tuples ... unless it's DECLARE CURSOR or SELECT INTO */
- if (parsetree->utilityStmt == NULL &&
- parsetree->intoClause == NULL)
+ if (parsetree->utilityStmt == NULL)
return true;
break;
case CMD_INSERT:
@@ -1907,6 +1905,13 @@ CreateCommandTag(Node *parsetree)
tag = "EXPLAIN";
break;
+ case T_CreateTableAsStmt:
+ if (((CreateTableAsStmt*)parsetree)->is_select_into)
+ tag = "SELECT INTO";
+ else
+ tag = "CREATE TABLE AS";
+ break;
+
case T_VariableSetStmt:
switch (((VariableSetStmt *) parsetree)->kind)
{
@@ -2060,8 +2065,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2110,8 +2113,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2178,10 +2179,7 @@ GetCommandLogLevel(Node *parsetree)
break;
case T_SelectStmt:
- if (((SelectStmt *) parsetree)->intoClause)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL;
+ lev = LOGSTMT_ALL;
break;
/* utility statements --- same whether raw or cooked */
@@ -2429,6 +2427,10 @@ GetCommandLogLevel(Node *parsetree)
}
break;
+ case T_CreateTableAsStmt:
+ lev = LOGSTMT_DDL;
+ break;
+
case T_VariableSetStmt:
lev = LOGSTMT_ALL;
break;
@@ -2529,10 +2531,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
@@ -2558,10 +2557,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
diff --git a/src/include/access/htup.h b/src/include/access/htup.h
index 6a3778d..abbc152 100644
--- a/src/include/access/htup.h
+++ b/src/include/access/htup.h
@@ -311,7 +311,7 @@ do { \
#define HeapTupleHeaderSetOid(tup, oid) \
do { \
- Assert((tup)->t_infomask & HEAP_HASOID); \
+ if(!((tup)->t_infomask & HEAP_HASOID)) elog(ERROR, "HEAP_HASOID"); \
*((Oid *) ((char *)(tup) + (tup)->t_hoff - sizeof(Oid))) = (oid); \
} while (0)
diff --git a/src/include/commands/prepare.h b/src/include/commands/prepare.h
index 472a357..6b545dc 100644
--- a/src/include/commands/prepare.h
+++ b/src/include/commands/prepare.h
@@ -54,4 +54,7 @@ extern List *FetchPreparedStatementTargetList(PreparedStatement *stmt);
void DropAllPreparedStatements(void);
+extern ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
+ const char *queryString, EState *estate);
+
#endif /* PREPARE_H */
diff --git a/src/include/commands/tablecmds.h b/src/include/commands/tablecmds.h
index 03f397d..212a51d 100644
--- a/src/include/commands/tablecmds.h
+++ b/src/include/commands/tablecmds.h
@@ -15,6 +15,7 @@
#define TABLECMDS_H
#include "access/htup.h"
+#include "executor/executor.h"
#include "nodes/parsenodes.h"
#include "storage/lock.h"
#include "utils/relcache.h"
@@ -22,6 +23,9 @@
extern Oid DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId);
+extern void CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest);
+
extern void RemoveRelations(DropStmt *drop);
extern Oid AlterTableLookupRelation(AlterTableStmt *stmt, LOCKMODE lockmode);
diff --git a/src/include/executor/executor.h b/src/include/executor/executor.h
index 7f27669..47bd1ee 100644
--- a/src/include/executor/executor.h
+++ b/src/include/executor/executor.h
@@ -49,12 +49,17 @@
* AfterTriggerBeginQuery/AfterTriggerEndQuery. This does not necessarily
* mean that the plan can't queue any AFTER triggers; just that the caller
* is responsible for there being a trigger context for them to be queued in.
+ *
+ * FORCE_OIDS tells the executor to build a tupleDesc that includes
+ * the oid column. This is used from tablecmd.c's CreateTableAs.
*/
#define EXEC_FLAG_EXPLAIN_ONLY 0x0001 /* EXPLAIN, no ANALYZE */
#define EXEC_FLAG_REWIND 0x0002 /* need efficient rescan */
#define EXEC_FLAG_BACKWARD 0x0004 /* need backward scan */
#define EXEC_FLAG_MARK 0x0008 /* need mark/restore */
#define EXEC_FLAG_SKIP_TRIGGERS 0x0010 /* skip AfterTrigger calls */
+#define EXEC_FLAG_FORCE_OIDS_ON 0x0020 /* force oids in returned tuples */
+#define EXEC_FLAG_FORCE_OIDS_OFF 0x0040 /* force oids in returned tuples */
/*
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 5207102..d268fb9 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -322,6 +322,12 @@ typedef struct ResultRelInfo
ProjectionInfo *ri_projectReturning;
} ResultRelInfo;
+typedef enum {
+ ESTATE_FORCE_OIDS_DEFAULT,
+ ESTATE_FORCE_OIDS_ON,
+ ESTATE_FORCE_OIDS_OFF
+} EStateForceOids;
+
/* ----------------
* EState information
*
@@ -371,8 +377,7 @@ typedef struct EState
int es_top_eflags; /* eflags passed to ExecutorStart */
int es_instrument; /* OR of InstrumentOption flags */
- bool es_select_into; /* true if doing SELECT INTO */
- bool es_into_oids; /* true to generate OIDs in SELECT INTO */
+ EStateForceOids es_force_oids; /* used by CreateTableAs */
bool es_finished; /* true when ExecutorFinish is done */
List *es_exprcontexts; /* List of ExprContexts within EState */
diff --git a/src/include/nodes/nodes.h b/src/include/nodes/nodes.h
index 0e7d184..f4d9ce2 100644
--- a/src/include/nodes/nodes.h
+++ b/src/include/nodes/nodes.h
@@ -304,6 +304,7 @@ typedef enum NodeTag
T_DropdbStmt,
T_VacuumStmt,
T_ExplainStmt,
+ T_CreateTableAsStmt,
T_CreateSeqStmt,
T_AlterSeqStmt,
T_VariableSetStmt,
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index ab55639..5c2797c 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -111,8 +111,6 @@ typedef struct Query
int resultRelation; /* rtable index of target relation for
* INSERT/UPDATE/DELETE; 0 for SELECT */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
bool hasAggs; /* has aggregates in tlist or havingQual */
bool hasWindowFuncs; /* has window functions in tlist */
bool hasSubLinks; /* has subquery SubLink */
@@ -1009,7 +1007,7 @@ typedef struct SelectStmt
*/
List *distinctClause; /* NULL, list of DISTINCT ON exprs, or
* lcons(NIL,NIL) for all (SELECT DISTINCT) */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
+ IntoClause *intoClause; /* target for SELECT INTO */
List *targetList; /* the target list (of ResTarget) */
List *fromClause; /* the FROM clause */
Node *whereClause; /* WHERE qualification */
@@ -2384,7 +2382,7 @@ typedef struct VacuumStmt
* Explain Statement
*
* The "query" field is either a raw parse tree (SelectStmt, InsertStmt, etc)
- * or a Query node if parse analysis has been done. Note that rewriting and
+ * or a Query node if parse analysis has been done. Note that rewriting and
* planning of the query are always postponed until execution of EXPLAIN.
* ----------------------
*/
@@ -2396,6 +2394,19 @@ typedef struct ExplainStmt
} ExplainStmt;
/* ----------------------
+ * analyzing, rewriting and planning are handled as in explain
+ * statements (see comment above) only that query can only be a
+ * SelectStmt and not some other type.
+ */
+typedef struct CreateTableAsStmt
+{
+ NodeTag type;
+ IntoClause *into;
+ Node *query; /* the query (see comments above) */
+ bool is_select_into; /* plpgsql wants to disambiguate */
+} CreateTableAsStmt;
+
+/* ----------------------
* Checkpoint Statement
* ----------------------
*/
@@ -2509,7 +2520,6 @@ typedef struct ExecuteStmt
{
NodeTag type;
char *name; /* The name of the plan to execute */
- IntoClause *into; /* Optional table to store results in */
List *params; /* Values to assign to parameters */
} ExecuteStmt;
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 7d90b91..b67d988 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -54,8 +54,6 @@ typedef struct PlannedStmt
Node *utilityStmt; /* non-null if this is DECLARE CURSOR */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
List *subplans; /* Plan trees for SubPlan expressions */
Bitmapset *rewindPlanIDs; /* indices of subplans that require REWIND */
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 0b126a3..231210a 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -3286,29 +3286,18 @@ exec_stmt_dynexecute(PLpgSQL_execstate *estate,
break;
case SPI_OK_SELINTO:
-
/*
* We want to disallow SELECT INTO for now, because its behavior
* is not consistent with SELECT INTO in a normal plpgsql context.
* (We need to reimplement EXECUTE to parse the string as a
* plpgsql command, not just feed it to SPI_execute.) However,
- * CREATE AS should be allowed ... and since it produces the same
- * parsetree as SELECT INTO, there's no way to tell the difference
- * except to look at the source text. Wotta kluge!
+ * CREATE AS should be allowed ...
*/
- {
- char *ptr;
-
- for (ptr = querystr; *ptr; ptr++)
- if (!scanner_isspace(*ptr))
- break;
- if (*ptr == 'S' || *ptr == 's')
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("EXECUTE of SELECT ... INTO is not implemented"),
- errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
- break;
- }
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("EXECUTE of SELECT ... INTO is not implemented"),
+ errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
+ break;
/* Some SPI errors deserve specific error messages */
case SPI_ERROR_COPY:
@@ -5759,7 +5748,7 @@ exec_simple_check_plan(PLpgSQL_expr *expr)
*/
if (!IsA(query, Query))
return;
- if (query->commandType != CMD_SELECT || query->intoClause)
+ if (query->commandType != CMD_SELECT)
return;
if (query->rtable != NIL)
return;
@@ -5833,7 +5822,7 @@ exec_simple_recheck_plan(PLpgSQL_expr *expr, CachedPlan *cplan)
*/
if (!IsA(stmt, PlannedStmt))
return;
- if (stmt->commandType != CMD_SELECT || stmt->intoClause)
+ if (stmt->commandType != CMD_SELECT)
return;
plan = stmt->planTree;
if (!IsA(plan, Result))
diff --git a/src/test/regress/expected/select_into.out b/src/test/regress/expected/select_into.out
index c8327f6..d124382 100644
--- a/src/test/regress/expected/select_into.out
+++ b/src/test/regress/expected/select_into.out
@@ -44,6 +44,25 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
AS SELECT oid,relname,relacl FROM pg_class
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ERROR: DECLARE CURSOR cannot specify INTO
+LINE 1: DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ ^
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+ERROR: COPY (SELECT INTO) is not supported
+SELECT * FROM (SELECT 1 INTO f) bar;
+ERROR: subquery in FROM cannot have SELECT INTO
+LINE 1: SELECT * FROM (SELECT 1 INTO f) bar;
+ ^
+CREATE VIEW foo AS SELECT 1 INTO b;
+ERROR: views must not contain SELECT INTO
+INSERT INTO b SELECT 1 INTO f;
+ERROR: INSERT ... SELECT cannot specify INTO
+LINE 1: INSERT INTO b SELECT 1 INTO f;
+ ^
DROP SCHEMA selinto_schema CASCADE;
NOTICE: drop cascades to 3 other objects
DETAIL: drop cascades to table selinto_schema.tmp1
diff --git a/src/test/regress/expected/transactions.out b/src/test/regress/expected/transactions.out
index e9d3908..6981692 100644
--- a/src/test/regress/expected/transactions.out
+++ b/src/test/regress/expected/transactions.out
@@ -139,7 +139,7 @@ SELECT * FROM writetest, temptest; -- ok
(0 rows)
CREATE TABLE test AS SELECT * FROM writetest; -- fail
-ERROR: cannot execute SELECT INTO in a read-only transaction
+ERROR: cannot execute CREATE TABLE AS in a read-only transaction
START TRANSACTION READ WRITE;
DROP TABLE writetest; -- ok
COMMIT;
diff --git a/src/test/regress/sql/select_into.sql b/src/test/regress/sql/select_into.sql
index 09d210b..0c07f76 100644
--- a/src/test/regress/sql/select_into.sql
+++ b/src/test/regress/sql/select_into.sql
@@ -50,6 +50,21 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+
+SELECT * FROM (SELECT 1 INTO f) bar;
+
+CREATE VIEW foo AS SELECT 1 INTO b;
+
+INSERT INTO b SELECT 1 INTO f;
+
+
DROP SCHEMA selinto_schema CASCADE;
DROP USER selinto_user;
--
1.7.9
ctas-on-command-triggers-01.patch (text/x-patch, 76.7K) download
From 954990feb665b6a1ce35968d7acf77e0d1356502 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Sun, 4 Mar 2012 16:45:01 +0100
Subject: [PATCH] Transform CREATE TABLE AS/SELECT INTO into a utility
statement
Conflicts:
src/include/commands/tablecmds.h
---
src/backend/commands/copy.c | 20 +-
src/backend/commands/prepare.c | 69 +----
src/backend/commands/tablecmds.c | 335 +++++++++++++++++++++
src/backend/commands/view.c | 20 +-
src/backend/executor/execMain.c | 441 ++--------------------------
src/backend/executor/execUtils.c | 2 -
src/backend/executor/functions.c | 4 +-
src/backend/executor/spi.c | 10 +-
src/backend/nodes/copyfuncs.c | 18 +-
src/backend/nodes/equalfuncs.c | 16 +-
src/backend/nodes/outfuncs.c | 4 +-
src/backend/nodes/readfuncs.c | 1 -
src/backend/optimizer/plan/planner.c | 1 -
src/backend/optimizer/plan/subselect.c | 1 -
src/backend/optimizer/prep/prepjointree.c | 6 +-
src/backend/optimizer/util/clauses.c | 4 +-
src/backend/parser/analyze.c | 113 +++++---
src/backend/parser/gram.y | 28 ++-
src/backend/parser/parse_clause.c | 21 +-
src/backend/parser/parse_cte.c | 21 +-
src/backend/parser/parse_expr.c | 21 +-
src/backend/parser/parser.c | 38 +++
src/backend/rewrite/rewriteDefine.c | 3 +-
src/backend/tcop/pquery.c | 13 +-
src/backend/tcop/utility.c | 46 ++--
src/include/access/htup.h | 2 +-
src/include/commands/prepare.h | 3 +
src/include/commands/tablecmds.h | 4 +
src/include/executor/executor.h | 5 +
src/include/nodes/execnodes.h | 9 +-
src/include/nodes/nodes.h | 1 +
src/include/nodes/parsenodes.h | 20 +-
src/include/nodes/plannodes.h | 2 -
src/pl/plpgsql/src/pl_exec.c | 27 +--
src/test/regress/expected/select_into.out | 19 ++
src/test/regress/expected/transactions.out | 2 +-
src/test/regress/sql/select_into.sql | 15 +
37 files changed, 720 insertions(+), 645 deletions(-)
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 110480f..a3c5b4b 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -1190,6 +1190,20 @@ BeginCopy(bool is_from,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY (SELECT) WITH OIDS is not supported")));
+
+ /* Query mustn't use INTO, either */
+ if(IsA(raw_query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)raw_query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("COPY (SELECT INTO) is not supported")));
+ }
+
/*
* Run parse analysis and rewrite. Note this also acquires sufficient
* locks on the source table(s).
@@ -1211,12 +1225,6 @@ BeginCopy(bool is_from,
Assert(query->commandType == CMD_SELECT);
Assert(query->utilityStmt == NULL);
- /* Query mustn't use INTO, either */
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("COPY (SELECT INTO) is not supported")));
-
/* plan the query */
plan = planner(query, 0, NULL);
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 4883abe..86e8cf9 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -43,8 +43,6 @@
static HTAB *prepared_queries = NULL;
static void InitQueryHashTable(void);
-static ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
- const char *queryString, EState *estate);
static Datum build_regtype_array(Oid *param_types, int num_params);
/*
@@ -177,6 +175,9 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
* EXECUTE, which we might need for error reporting while processing the
* parameter expressions. The query_string that we copy from the plan
* source is that of the original PREPARE.
+ *
+ * If you add additional things here you should check whether
+ * CreateTableAs also needs them.
*/
void
ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
@@ -222,51 +223,9 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
query_string = MemoryContextStrdup(PortalGetHeapMemory(portal),
entry->plansource->query_string);
- /*
- * For CREATE TABLE / AS EXECUTE, we must make a copy of the stored query
- * so that we can modify its destination (yech, but this has always been
- * ugly). For regular EXECUTE we can just use the cached query, since the
- * executor is read-only.
- */
- if (stmt->into)
- {
- MemoryContext oldContext;
- PlannedStmt *pstmt;
-
- /* Replan if needed, and increment plan refcount transiently */
- cplan = GetCachedPlan(entry->plansource, paramLI, true);
-
- /* Copy plan into portal's context, and modify */
- oldContext = MemoryContextSwitchTo(PortalGetHeapMemory(portal));
-
- plan_list = copyObject(cplan->stmt_list);
-
- if (list_length(plan_list) != 1)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt = (PlannedStmt *) linitial(plan_list);
- if (!IsA(pstmt, PlannedStmt) ||
- pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt->intoClause = copyObject(stmt->into);
-
- MemoryContextSwitchTo(oldContext);
-
- /* We no longer need the cached plan refcount ... */
- ReleaseCachedPlan(cplan, true);
- /* ... and we don't want the portal to depend on it, either */
- cplan = NULL;
- }
- else
- {
- /* Replan if needed, and increment plan refcount for portal */
- cplan = GetCachedPlan(entry->plansource, paramLI, false);
- plan_list = cplan->stmt_list;
- }
+ /* Replan if needed, and increment plan refcount for portal */
+ cplan = GetCachedPlan(entry->plansource, paramLI, false);
+ plan_list = cplan->stmt_list;
PortalDefineQuery(portal,
NULL,
@@ -302,7 +261,7 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
* CreateQueryDesc(), which allows the executor to make use of the parameters
* during query execution.
*/
-static ParamListInfo
+ParamListInfo
EvaluateParams(PreparedStatement *pstmt, List *params,
const char *queryString, EState *estate)
{
@@ -666,20 +625,6 @@ ExplainExecuteQuery(ExecuteStmt *execstmt, ExplainState *es,
if (IsA(pstmt, PlannedStmt))
{
- if (execstmt->into)
- {
- if (pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
-
- /* Copy the stmt so we can modify it */
- pstmt = copyObject(pstmt);
-
- pstmt->intoClause = execstmt->into;
- }
-
ExplainOnePlan(pstmt, es, query_string, paramLI);
}
else
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 1797e4d..cd59779 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -45,6 +45,7 @@
#include "commands/cluster.h"
#include "commands/comment.h"
#include "commands/defrem.h"
+#include "commands/prepare.h"
#include "commands/sequence.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
@@ -69,6 +70,7 @@
#include "parser/parser.h"
#include "rewrite/rewriteDefine.h"
#include "rewrite/rewriteHandler.h"
+#include "tcop/tcopprot.h"
#include "storage/bufmgr.h"
#include "storage/lmgr.h"
#include "storage/lock.h"
@@ -197,6 +199,18 @@ struct dropmsgstrings
const char *drophint_msg;
};
+/*
+ * Support structure for CTAS
+ */
+typedef struct
+{
+ DestReceiver pub; /* publicly-known function pointers */
+ EState *estate; /* EState we are working with */
+ Relation rel; /* Relation to write to */
+ int hi_options; /* heap_insert performance options */
+ BulkInsertState bistate; /* bulk insert state */
+} DR_intorel;
+
static const struct dropmsgstrings dropmsgstringarray[] = {
{RELKIND_RELATION,
ERRCODE_UNDEFINED_TABLE,
@@ -673,6 +687,235 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
return relationId;
}
+void
+CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest){
+ IntoClause *into = stmt->into;
+ Query *query;
+ List *rewritten;
+ PlannedStmt *plan;
+ QueryDesc *queryDesc;
+ Relation intoRelationDesc;
+ CreateStmt *create;
+ int natt;
+ Oid intoRelationId;
+ ListCell *lc;
+ int eflags = 0;
+ EState *param_estate = NULL;
+ CachedPlan *cplan = NULL;
+
+ Assert(IsA(stmt->query, Query));
+ query = (Query*)stmt->query;
+
+ /*
+ * Construct plans for the supported
+ */
+ if(query->commandType == CMD_SELECT){
+ rewritten = QueryRewrite((Query *) copyObject(stmt->query));
+
+ if(!rewritten)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to nothing");
+
+ if(list_length(rewritten) != 1)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to more than one query");
+
+ plan = pg_plan_query(lfirst(list_head(rewritten)), 0, params);
+ }
+ else if(query->commandType == CMD_UTILITY &&
+ IsA(query->utilityStmt, ExecuteStmt)){
+ /*
+ * We cannot easily share more infrastructure with prepare.c's
+ * ExecuteQuery because teaching it to return a started
+ * executor would amount to about the same amount of
+ * duplication as doing it here.
+ *
+ */
+ ExecuteStmt *stmt;
+ PreparedStatement *entry;
+ List *plan_list;
+ ParamListInfo paramLI = NULL;
+
+ Assert(IsA(query->utilityStmt, ExecuteStmt));
+ stmt = (ExecuteStmt*)(query->utilityStmt);
+
+ entry = FetchPreparedStatement(stmt->name, true);
+
+ /* Shouldn't find a non-fixed-result cached plan */
+ if (!entry->plansource->fixed_result)
+ elog(ERROR, "EXECUTE does not support variable-result cached plans");
+
+ /* Evaluate parameters, if any */
+ if (entry->plansource->num_params > 0)
+ {
+ param_estate = CreateExecutorState();
+ param_estate->es_param_list_info = params;
+ paramLI = EvaluateParams(entry, stmt->params,
+ queryString, param_estate);
+
+ }
+
+ cplan = GetCachedPlan(entry->plansource, paramLI, true);
+ plan_list = cplan->stmt_list;
+
+ if (list_length(plan_list) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ plan = (PlannedStmt *) linitial(plan_list);
+ if (!IsA(plan, PlannedStmt) ||
+ plan->commandType != CMD_SELECT ||
+ plan->utilityStmt != NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ queryString = pstrdup(entry->plansource->query_string);
+ }
+ else{
+ elog(ERROR, "unsupported command for CREATE TABLE AS");
+ abort();//silence compiler
+ }
+
+
+ /*
+ * Use a snapshot with an updated command ID to ensure this query sees
+ * results of any previously executed queries.
+ */
+ PushCopiedSnapshot(GetActiveSnapshot());
+ UpdateActiveSnapshotCommandId();
+
+ queryDesc = CreateQueryDesc(plan, queryString,
+ GetActiveSnapshot(), InvalidSnapshot,
+ CreateDestReceiver(DestIntoRel), params,
+ false);
+
+ /*
+ * We need to tell the executor whether it has to produce oids or
+ * not because it doesn't have enough information to do so itself
+ * as were not telling it that its inserting into a table (because
+ * that would be too complicated for now)
+ */
+ if(interpretOidsOption(into->options))
+ eflags |= EXEC_FLAG_FORCE_OIDS_ON;
+ else
+ eflags |= EXEC_FLAG_FORCE_OIDS_OFF;
+
+ /*
+ * call ExecutorStart to prepare the plan for execution. Only
+ * after this we have enough information to actually create a
+ * target relation
+ */
+ ExecutorStart(queryDesc, eflags);
+
+ /*
+ * create the target relation
+ */
+ create = makeNode(CreateStmt);
+ create->relation = into->rel;
+ create->options = into->options;
+ create->oncommit = into->onCommit;
+ create->tablespacename = into->tableSpaceName;
+
+ /*
+ * If a column name list was specified in CREATE TABLE AS,
+ * override the column names derived from the query. (Too few
+ * column names are OK, too many are not.)
+ */
+ if (list_length(into->colNames) > queryDesc->tupDesc->natts)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("CREATE TABLE AS specifies too many column names")));
+ lc = list_head(into->colNames);
+ for(natt = 0; natt < queryDesc->tupDesc->natts; natt++){
+ ColumnDef *col = makeNode(ColumnDef);
+ TypeName *type = makeNode(TypeName);
+
+ Form_pg_attribute attribute = queryDesc->tupDesc->attrs[natt];
+
+ if(!lc)
+ col->colname = NameStr(attribute->attname);
+ else{
+ col->colname = strVal(lfirst(lc));
+ lc = lnext(lc);
+ }
+
+ col->collOid = attribute->attcollation;
+
+ type->typeOid = attribute->atttypid;
+ type->typemod = attribute->atttypmod;
+ col->typeName= type;
+
+ /*
+ * We check the column type here because collOid=InvalidOid
+ * denotes an invalid oid for a collatable type in
+ * queryDesc->tupDesc but GetColumnDefCollation - which will
+ * be called by DefineRelation - defers the default collation
+ * out of that...
+ * XXX: A better solution would be welcome.
+ */
+ CheckAttributeType(col->colname, col->typeName->typeOid, col->collOid,
+ NULL, false);
+ create->tableElts = lappend(create->tableElts, col);
+ }
+
+ /*
+ * Actually create the target table
+ */
+ intoRelationId = DefineRelation(create, RELKIND_RELATION, InvalidOid);
+ intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
+
+
+ if(!into->skipData){
+ DR_intorel *myState = (DR_intorel *) queryDesc->dest;
+ /* setup the target of the DestIntoRel receiver */
+ myState->estate = queryDesc->estate;
+ myState->rel = intoRelationDesc;
+
+ /* run the plan */
+ ExecutorRun(queryDesc, ForwardScanDirection, 0L);
+
+ }
+
+ /*
+ * Check INSERT permission on the constructed table.
+ *
+ * XXX: It would arguable make sense to do this check only if
+ * into->skipData is true.
+ */
+ {
+ RangeTblEntry *rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = intoRelationId;
+ rte->relkind = RELKIND_RELATION;
+ rte->requiredPerms = ACL_INSERT;
+
+ for (natt = 1; natt <= intoRelationDesc->rd_att->natts; natt++)
+ rte->modifiedCols = bms_add_member(rte->modifiedCols,
+ natt - FirstLowInvalidHeapAttributeNumber);
+
+ ExecCheckRTPerms(list_make1(rte), true);
+ }
+
+ /* run cleanup too */
+ ExecutorFinish(queryDesc);
+ ExecutorEnd(queryDesc);
+
+ /* close rel, but keep lock until commit */
+ heap_close(intoRelationDesc, NoLock);
+
+ FreeQueryDesc(queryDesc);
+
+ if(cplan){
+ ReleaseCachedPlan(cplan, true);
+
+ if (param_estate)
+ FreeExecutorState(param_estate);
+ }
+
+ PopActiveSnapshot();
+}
+
/*
* Emit the right error or warning message for a "DROP" command issued on a
* non-existent relation
@@ -10306,3 +10549,95 @@ RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid, Oid oldrelid,
ReleaseSysCache(tuple);
}
+
+/*
+ * Support for SELECT INTO (aka CREATE TABLE AS)
+ *
+ * We implement SELECT INTO by diverting SELECT's normal output with
+ * a specialized DestReceiver type.
+ */
+
+/*
+ * intorel_startup --- executor startup
+ */
+static void
+intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ myState->bistate = GetBulkInsertState();
+ myState->hi_options = HEAP_INSERT_SKIP_FSM;
+ if (!XLogIsNeeded())
+ myState->hi_options |= HEAP_INSERT_SKIP_WAL;
+
+}
+
+/*
+ * intorel_receive --- receive one tuple
+ */
+static void
+intorel_receive(TupleTableSlot *slot, DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ HeapTuple tuple;
+
+ /*
+ * get the heap tuple out of the tuple table slot, making sure we have a
+ * writable copy
+ */
+ tuple = ExecMaterializeSlot(slot);
+
+ /*
+ * force assignment of new OID (see comments in ExecInsert)
+ */
+ if (myState->rel->rd_rel->relhasoids)
+ HeapTupleSetOid(tuple, InvalidOid);
+
+ heap_insert(myState->rel,
+ tuple,
+ myState->estate->es_output_cid,
+ myState->hi_options,
+ myState->bistate);
+
+ /* We know this is a newly created relation, so there are no indexes */
+}
+
+/*
+ * intorel_shutdown --- executor end
+ */
+static void
+intorel_shutdown(DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+
+ FreeBulkInsertState(myState->bistate);
+ if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
+ heap_sync(myState->rel);
+}
+
+/*
+ * intorel_destroy --- release DestReceiver object
+ */
+static void
+intorel_destroy(DestReceiver *self)
+{
+ pfree(self);
+}
+
+/*
+ * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
+ *
+ */
+DestReceiver *
+CreateIntoRelDestReceiver(void)
+{
+ DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
+
+ self->pub.receiveSlot = intorel_receive;
+ self->pub.rStartup = intorel_startup;
+ self->pub.rShutdown = intorel_shutdown;
+ self->pub.rDestroy = intorel_destroy;
+ self->pub.mydest = DestIntoRel;
+ /* private fields will be set on startup */
+
+ return (DestReceiver *) self;
+}
diff --git a/src/backend/commands/view.c b/src/backend/commands/view.c
index 09c6001..e12b17b 100644
--- a/src/backend/commands/view.c
+++ b/src/backend/commands/view.c
@@ -443,6 +443,22 @@ DefineView(ViewStmt *stmt, const char *queryString)
CommandContextData cmd;
/*
+ * We check for SELECT INTO before parse analysis because that
+ * would complain about the SELECT INTO without specific enough detail.
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("views must not contain SELECT INTO")));
+ }
+
+ /*
* Run parse analysis to convert the raw parse tree to a Query. Note this
* also acquires sufficient locks on the source table(s).
*
@@ -464,10 +480,6 @@ DefineView(ViewStmt *stmt, const char *queryString)
* DefineQueryRewrite(), but that function will complain about a bogus ON
* SELECT rule, and we'd rather the message complain about a view.
*/
- if (viewParse->intoClause != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("views must not contain SELECT INTO")));
if (viewParse->hasModifyingCTE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 36dcc8e..1979325 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -90,12 +90,6 @@ static char *ExecBuildSlotValueDescription(TupleTableSlot *slot,
int maxfieldlen);
static void EvalPlanQualStart(EPQState *epqstate, EState *parentestate,
Plan *planTree);
-static void OpenIntoRel(QueryDesc *queryDesc);
-static void CloseIntoRel(QueryDesc *queryDesc);
-static void intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo);
-static void intorel_receive(TupleTableSlot *slot, DestReceiver *self);
-static void intorel_shutdown(DestReceiver *self);
-static void intorel_destroy(DestReceiver *self);
/* end of local decls */
@@ -174,11 +168,10 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
case CMD_SELECT:
/*
- * SELECT INTO, SELECT FOR UPDATE/SHARE and modifying CTEs need to
+ * SELECT FOR UPDATE/SHARE and modifying CTEs need to
* mark tuples
*/
- if (queryDesc->plannedstmt->intoClause != NULL ||
- queryDesc->plannedstmt->rowMarks != NIL ||
+ if (queryDesc->plannedstmt->rowMarks != NIL ||
queryDesc->plannedstmt->hasModifyingCTE)
estate->es_output_cid = GetCurrentCommandId(true);
@@ -212,6 +205,13 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
estate->es_top_eflags = eflags;
estate->es_instrument = queryDesc->instrument_options;
+ if(eflags & EXEC_FLAG_FORCE_OIDS_ON)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_ON;
+ else if(eflags & EXEC_FLAG_FORCE_OIDS_OFF)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_OFF;
+ else
+ estate->es_force_oids = ESTATE_FORCE_OIDS_DEFAULT;
+
/*
* Initialize the plan state tree
*/
@@ -310,13 +310,6 @@ standard_ExecutorRun(QueryDesc *queryDesc,
(*dest->rStartup) (dest, operation, queryDesc->tupDesc);
/*
- * if it's CREATE TABLE AS ... WITH NO DATA, skip plan execution
- */
- if (estate->es_select_into &&
- queryDesc->plannedstmt->intoClause->skipData)
- direction = NoMovementScanDirection;
-
- /*
* run plan
*/
if (!ScanDirectionIsNoMovement(direction))
@@ -451,12 +444,6 @@ standard_ExecutorEnd(QueryDesc *queryDesc)
ExecEndPlan(queryDesc->planstate, estate);
- /*
- * Close the SELECT INTO relation if any
- */
- if (estate->es_select_into)
- CloseIntoRel(queryDesc);
-
/* do away with our snapshots */
UnregisterSnapshot(estate->es_snapshot);
UnregisterSnapshot(estate->es_crosscheck_snapshot);
@@ -706,15 +693,6 @@ ExecCheckXactReadOnly(PlannedStmt *plannedstmt)
{
ListCell *l;
- /*
- * CREATE TABLE AS or SELECT INTO?
- *
- * XXX should we allow this if the destination is temp? Considering that
- * it would still require catalog changes, probably not.
- */
- if (plannedstmt->intoClause != NULL)
- PreventCommandIfReadOnly(CreateCommandTag((Node *) plannedstmt));
-
/* Fail if write permissions are requested on any non-temp table */
foreach(l, plannedstmt->rtable)
{
@@ -864,18 +842,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
}
/*
- * Detect whether we're doing SELECT INTO. If so, set the es_into_oids
- * flag appropriately so that the plan tree will be initialized with the
- * correct tuple descriptors. (Other SELECT INTO stuff comes later.)
- */
- estate->es_select_into = false;
- if (operation == CMD_SELECT && plannedstmt->intoClause != NULL)
- {
- estate->es_select_into = true;
- estate->es_into_oids = interpretOidsOption(plannedstmt->intoClause->options);
- }
-
- /*
* Initialize the executor's tuple table to empty.
*/
estate->es_tupleTable = NIL;
@@ -926,9 +892,7 @@ InitPlan(QueryDesc *queryDesc, int eflags)
planstate = ExecInitNode(plan, estate, eflags);
/*
- * Get the tuple descriptor describing the type of tuples to return. (this
- * is especially important if we are creating a relation with "SELECT
- * INTO")
+ * Get the tuple descriptor describing the type of tuples to return.
*/
tupType = ExecGetResultType(planstate);
@@ -968,16 +932,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
queryDesc->tupDesc = tupType;
queryDesc->planstate = planstate;
-
- /*
- * If doing SELECT INTO, initialize the "into" relation. We must wait
- * till now so we have the "clean" result tuple type to create the new
- * table from.
- *
- * If EXPLAIN, skip creating the "into" relation.
- */
- if (estate->es_select_into && !(eflags & EXEC_FLAG_EXPLAIN_ONLY))
- OpenIntoRel(queryDesc);
}
/*
@@ -1230,7 +1184,7 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
/*
* ExecContextForcesOids
*
- * This is pretty grotty: when doing INSERT, UPDATE, or SELECT INTO,
+ * This is pretty grotty: when doing INSERT or UPDATE
* we need to ensure that result tuples have space for an OID iff they are
* going to be stored into a relation that has OIDs. In other contexts
* we are free to choose whether to leave space for OIDs in result tuples
@@ -1255,15 +1209,25 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
* the ModifyTable node, so ModifyTable has to set es_result_relation_info
* while initializing each subplan.
*
- * SELECT INTO is even uglier, because we don't have the INTO relation's
- * descriptor available when this code runs; we have to look aside at a
- * flag set by InitPlan().
+ * SELECT INTO is even uglier, because we don't have the INTO
+ * relation's descriptor available - because its only defined after
+ * the query started - when this code runs; we have to look aside at
+ * flags which is passed to ExecutorStart via eflags.
*/
bool
ExecContextForcesOids(PlanState *planstate, bool *hasoids)
{
ResultRelInfo *ri = planstate->state->es_result_relation_info;
+ if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_ON){
+ *hasoids = true;
+ return true;
+ }
+ else if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_OFF){
+ *hasoids = false;
+ return true;
+ }
+
if (ri != NULL)
{
Relation rel = ri->ri_RelationDesc;
@@ -1275,12 +1239,6 @@ ExecContextForcesOids(PlanState *planstate, bool *hasoids)
}
}
- if (planstate->state->es_select_into)
- {
- *hasoids = planstate->state->es_into_oids;
- return true;
- }
-
return false;
}
@@ -2290,8 +2248,7 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
estate->es_rowMarks = parentestate->es_rowMarks;
estate->es_top_eflags = parentestate->es_top_eflags;
estate->es_instrument = parentestate->es_instrument;
- estate->es_select_into = parentestate->es_select_into;
- estate->es_into_oids = parentestate->es_into_oids;
+
/* es_auxmodifytables must NOT be copied */
/*
@@ -2423,351 +2380,3 @@ EvalPlanQualEnd(EPQState *epqstate)
epqstate->planstate = NULL;
epqstate->origslot = NULL;
}
-
-
-/*
- * Support for SELECT INTO (a/k/a CREATE TABLE AS)
- *
- * We implement SELECT INTO by diverting SELECT's normal output with
- * a specialized DestReceiver type.
- */
-
-typedef struct
-{
- DestReceiver pub; /* publicly-known function pointers */
- EState *estate; /* EState we are working with */
- DestReceiver *origdest; /* QueryDesc's original receiver */
- Relation rel; /* Relation to write to */
- int hi_options; /* heap_insert performance options */
- BulkInsertState bistate; /* bulk insert state */
-} DR_intorel;
-
-/*
- * OpenIntoRel --- actually create the SELECT INTO target relation
- *
- * This also replaces QueryDesc->dest with the special DestReceiver for
- * SELECT INTO. We assume that the correct result tuple type has already
- * been placed in queryDesc->tupDesc.
- */
-static void
-OpenIntoRel(QueryDesc *queryDesc)
-{
- IntoClause *into = queryDesc->plannedstmt->intoClause;
- EState *estate = queryDesc->estate;
- TupleDesc intoTupDesc = queryDesc->tupDesc;
- Relation intoRelationDesc;
- char *intoName;
- Oid namespaceId;
- Oid tablespaceId;
- Datum reloptions;
- Oid intoRelationId;
- DR_intorel *myState;
- RangeTblEntry *rte;
- AttrNumber attnum;
- static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
-
- Assert(into);
-
- /*
- * XXX This code needs to be kept in sync with DefineRelation(). Maybe we
- * should try to use that function instead.
- */
-
- /*
- * Check consistency of arguments
- */
- if (into->onCommit != ONCOMMIT_NOOP
- && into->rel->relpersistence != RELPERSISTENCE_TEMP)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
- errmsg("ON COMMIT can only be used on temporary tables")));
-
- {
- AclResult aclresult;
- int i;
-
- for (i = 0; i < intoTupDesc->natts; i++)
- {
- Oid atttypid = intoTupDesc->attrs[i]->atttypid;
-
- aclresult = pg_type_aclcheck(atttypid, GetUserId(), ACL_USAGE);
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TYPE,
- format_type_be(atttypid));
- }
- }
-
- /*
- * If a column name list was specified in CREATE TABLE AS, override the
- * column names derived from the query. (Too few column names are OK, too
- * many are not.) It would probably be all right to scribble directly on
- * the query's result tupdesc, but let's be safe and make a copy.
- */
- if (into->colNames)
- {
- ListCell *lc;
-
- intoTupDesc = CreateTupleDescCopy(intoTupDesc);
- attnum = 1;
- foreach(lc, into->colNames)
- {
- char *colname = strVal(lfirst(lc));
-
- if (attnum > intoTupDesc->natts)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("CREATE TABLE AS specifies too many column names")));
- namestrcpy(&(intoTupDesc->attrs[attnum - 1]->attname), colname);
- attnum++;
- }
- }
-
- /*
- * Find namespace to create in, check its permissions, lock it against
- * concurrent drop, and mark into->rel as RELPERSISTENCE_TEMP if the
- * selected namespace is temporary.
- */
- intoName = into->rel->relname;
- namespaceId = RangeVarGetAndCheckCreationNamespace(into->rel, NoLock,
- NULL);
-
- /*
- * Security check: disallow creating temp tables from security-restricted
- * code. This is needed because calling code might not expect untrusted
- * tables to appear in pg_temp at the front of its search path.
- */
- if (into->rel->relpersistence == RELPERSISTENCE_TEMP
- && InSecurityRestrictedOperation())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("cannot create temporary table within security-restricted operation")));
-
- /*
- * Select tablespace to use. If not specified, use default tablespace
- * (which may in turn default to database's default).
- */
- if (into->tableSpaceName)
- {
- tablespaceId = get_tablespace_oid(into->tableSpaceName, false);
- }
- else
- {
- tablespaceId = GetDefaultTablespace(into->rel->relpersistence);
- /* note InvalidOid is OK in this case */
- }
-
- /* Check permissions except when using the database's default space */
- if (OidIsValid(tablespaceId) && tablespaceId != MyDatabaseTableSpace)
- {
- AclResult aclresult;
-
- aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(),
- ACL_CREATE);
-
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TABLESPACE,
- get_tablespace_name(tablespaceId));
- }
-
- /* Parse and validate any reloptions */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- NULL,
- validnsps,
- true,
- false);
- (void) heap_reloptions(RELKIND_RELATION, reloptions, true);
-
- /* Now we can actually create the new relation */
- intoRelationId = heap_create_with_catalog(intoName,
- namespaceId,
- tablespaceId,
- InvalidOid,
- InvalidOid,
- InvalidOid,
- GetUserId(),
- intoTupDesc,
- NIL,
- RELKIND_RELATION,
- into->rel->relpersistence,
- false,
- false,
- true,
- 0,
- into->onCommit,
- reloptions,
- true,
- allowSystemTableMods);
- Assert(intoRelationId != InvalidOid);
-
- /*
- * Advance command counter so that the newly-created relation's catalog
- * tuples will be visible to heap_open.
- */
- CommandCounterIncrement();
-
- /*
- * If necessary, create a TOAST table for the INTO relation. Note that
- * AlterTableCreateToastTable ends with CommandCounterIncrement(), so that
- * the TOAST table will be visible for insertion.
- */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- "toast",
- validnsps,
- true,
- false);
-
- (void) heap_reloptions(RELKIND_TOASTVALUE, reloptions, true);
-
- AlterTableCreateToastTable(intoRelationId, reloptions);
-
- /*
- * And open the constructed table for writing.
- */
- intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
-
- /*
- * Check INSERT permission on the constructed table.
- */
- rte = makeNode(RangeTblEntry);
- rte->rtekind = RTE_RELATION;
- rte->relid = intoRelationId;
- rte->relkind = RELKIND_RELATION;
- rte->requiredPerms = ACL_INSERT;
-
- for (attnum = 1; attnum <= intoTupDesc->natts; attnum++)
- rte->modifiedCols = bms_add_member(rte->modifiedCols,
- attnum - FirstLowInvalidHeapAttributeNumber);
-
- ExecCheckRTPerms(list_make1(rte), true);
-
- /*
- * Now replace the query's DestReceiver with one for SELECT INTO
- */
- myState = (DR_intorel *) CreateDestReceiver(DestIntoRel);
- Assert(myState->pub.mydest == DestIntoRel);
- myState->estate = estate;
- myState->origdest = queryDesc->dest;
- myState->rel = intoRelationDesc;
-
- queryDesc->dest = (DestReceiver *) myState;
-
- /*
- * We can skip WAL-logging the insertions, unless PITR or streaming
- * replication is in use. We can skip the FSM in any case.
- */
- myState->hi_options = HEAP_INSERT_SKIP_FSM |
- (XLogIsNeeded() ? 0 : HEAP_INSERT_SKIP_WAL);
- myState->bistate = GetBulkInsertState();
-
- /* Not using WAL requires smgr_targblock be initially invalid */
- Assert(RelationGetTargetBlock(intoRelationDesc) == InvalidBlockNumber);
-}
-
-/*
- * CloseIntoRel --- clean up SELECT INTO at ExecutorEnd time
- */
-static void
-CloseIntoRel(QueryDesc *queryDesc)
-{
- DR_intorel *myState = (DR_intorel *) queryDesc->dest;
-
- /*
- * OpenIntoRel might never have gotten called, and we also want to guard
- * against double destruction.
- */
- if (myState && myState->pub.mydest == DestIntoRel)
- {
- FreeBulkInsertState(myState->bistate);
-
- /* If we skipped using WAL, must heap_sync before commit */
- if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
- heap_sync(myState->rel);
-
- /* close rel, but keep lock until commit */
- heap_close(myState->rel, NoLock);
-
- /* restore the receiver belonging to executor's caller */
- queryDesc->dest = myState->origdest;
-
- /* might as well invoke my destructor */
- intorel_destroy((DestReceiver *) myState);
- }
-}
-
-/*
- * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
- */
-DestReceiver *
-CreateIntoRelDestReceiver(void)
-{
- DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
-
- self->pub.receiveSlot = intorel_receive;
- self->pub.rStartup = intorel_startup;
- self->pub.rShutdown = intorel_shutdown;
- self->pub.rDestroy = intorel_destroy;
- self->pub.mydest = DestIntoRel;
-
- /* private fields will be set by OpenIntoRel */
-
- return (DestReceiver *) self;
-}
-
-/*
- * intorel_startup --- executor startup
- */
-static void
-intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
-{
- /* no-op */
-}
-
-/*
- * intorel_receive --- receive one tuple
- */
-static void
-intorel_receive(TupleTableSlot *slot, DestReceiver *self)
-{
- DR_intorel *myState = (DR_intorel *) self;
- HeapTuple tuple;
-
- /*
- * get the heap tuple out of the tuple table slot, making sure we have a
- * writable copy
- */
- tuple = ExecMaterializeSlot(slot);
-
- /*
- * force assignment of new OID (see comments in ExecInsert)
- */
- if (myState->rel->rd_rel->relhasoids)
- HeapTupleSetOid(tuple, InvalidOid);
-
- heap_insert(myState->rel,
- tuple,
- myState->estate->es_output_cid,
- myState->hi_options,
- myState->bistate);
-
- /* We know this is a newly created relation, so there are no indexes */
-}
-
-/*
- * intorel_shutdown --- executor end
- */
-static void
-intorel_shutdown(DestReceiver *self)
-{
- /* no-op */
-}
-
-/*
- * intorel_destroy --- release DestReceiver object
- */
-static void
-intorel_destroy(DestReceiver *self)
-{
- pfree(self);
-}
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index 6db42e7..40cd5ce 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -137,8 +137,6 @@ CreateExecutorState(void)
estate->es_top_eflags = 0;
estate->es_instrument = 0;
- estate->es_select_into = false;
- estate->es_into_oids = false;
estate->es_finished = false;
estate->es_exprcontexts = NIL;
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index 61f4622..ae8d374 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -535,7 +535,6 @@ init_execution_state(List *queryTree_list,
if (ps->commandType == CMD_SELECT &&
ps->utilityStmt == NULL &&
- ps->intoClause == NULL &&
!ps->hasModifyingCTE)
fcache->lazyEval = lasttages->lazyEval = true;
}
@@ -1493,8 +1492,7 @@ check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,
*/
if (parse &&
parse->commandType == CMD_SELECT &&
- parse->utilityStmt == NULL &&
- parse->intoClause == NULL)
+ parse->utilityStmt == NULL)
{
tlist_ptr = &parse->targetList;
tlist = parse->targetList;
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index 81f284c..ce6abcf 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.c
@@ -1917,7 +1917,11 @@ _SPI_execute_plan(SPIPlanPtr plan, ParamListInfo paramLI,
if (_SPI_current->tuptable)
_SPI_current->processed = _SPI_current->tuptable->alloced -
_SPI_current->tuptable->free;
- res = SPI_OK_UTILITY;
+ if(nodeTag(stmt) == T_CreateTableAsStmt &&
+ ((CreateTableAsStmt*)stmt)->is_select_into)
+ res = SPI_OK_SELINTO;
+ else
+ res = SPI_OK_UTILITY;
}
/*
@@ -2042,9 +2046,7 @@ _SPI_pquery(QueryDesc *queryDesc, bool fire_triggers, long tcount)
{
case CMD_SELECT:
Assert(queryDesc->plannedstmt->utilityStmt == NULL);
- if (queryDesc->plannedstmt->intoClause) /* select into table? */
- res = SPI_OK_SELINTO;
- else if (queryDesc->dest->mydest != DestSPI)
+ if (queryDesc->dest->mydest != DestSPI)
{
/* Don't return SPI_OK_SELECT if we're discarding result */
res = SPI_OK_UTILITY;
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 6a20a6c..790ff4c 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -85,7 +85,6 @@ _copyPlannedStmt(const PlannedStmt *from)
COPY_NODE_FIELD(rtable);
COPY_NODE_FIELD(resultRelations);
COPY_NODE_FIELD(utilityStmt);
- COPY_NODE_FIELD(intoClause);
COPY_NODE_FIELD(subplans);
COPY_BITMAPSET_FIELD(rewindPlanIDs);
COPY_NODE_FIELD(rowMarks);
@@ -2419,7 +2418,6 @@ _copyQuery(const Query *from)
COPY_SCALAR_FIELD(canSetTag);
COPY_NODE_FIELD(utilityStmt);
COPY_SCALAR_FIELD(resultRelation);
- COPY_NODE_FIELD(intoClause);
COPY_SCALAR_FIELD(hasAggs);
COPY_SCALAR_FIELD(hasWindowFuncs);
COPY_SCALAR_FIELD(hasSubLinks);
@@ -3207,6 +3205,18 @@ _copyExplainStmt(const ExplainStmt *from)
return newnode;
}
+static CreateTableAsStmt *
+_copyCreateTableAsStmt(CreateTableAsStmt *from)
+{
+ CreateTableAsStmt *newnode = makeNode(CreateTableAsStmt);
+
+ COPY_NODE_FIELD(query);
+ COPY_NODE_FIELD(into);
+ COPY_SCALAR_FIELD(is_select_into);
+
+ return newnode;
+}
+
static CreateSeqStmt *
_copyCreateSeqStmt(const CreateSeqStmt *from)
{
@@ -3638,7 +3648,6 @@ _copyExecuteStmt(const ExecuteStmt *from)
ExecuteStmt *newnode = makeNode(ExecuteStmt);
COPY_STRING_FIELD(name);
- COPY_NODE_FIELD(into);
COPY_NODE_FIELD(params);
return newnode;
@@ -4273,6 +4282,9 @@ copyObject(const void *from)
case T_ExplainStmt:
retval = _copyExplainStmt(from);
break;
+ case T_CreateTableAsStmt:
+ retval = _copyCreateTableAsStmt(from);
+ break;
case T_CreateSeqStmt:
retval = _copyCreateSeqStmt(from);
break;
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index 137075a..58194df 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -900,7 +900,6 @@ _equalQuery(const Query *a, const Query *b)
COMPARE_SCALAR_FIELD(canSetTag);
COMPARE_NODE_FIELD(utilityStmt);
COMPARE_SCALAR_FIELD(resultRelation);
- COMPARE_NODE_FIELD(intoClause);
COMPARE_SCALAR_FIELD(hasAggs);
COMPARE_SCALAR_FIELD(hasWindowFuncs);
COMPARE_SCALAR_FIELD(hasSubLinks);
@@ -1564,6 +1563,17 @@ _equalExplainStmt(const ExplainStmt *a, const ExplainStmt *b)
return true;
}
+
+static bool
+_equalCreateTableAsStmt(CreateTableAsStmt *a, CreateTableAsStmt *b)
+{
+ COMPARE_NODE_FIELD(query);
+ COMPARE_NODE_FIELD(into);
+ COMPARE_SCALAR_FIELD(is_select_into);
+
+ return true;
+}
+
static bool
_equalCreateSeqStmt(const CreateSeqStmt *a, const CreateSeqStmt *b)
{
@@ -1927,7 +1937,6 @@ static bool
_equalExecuteStmt(const ExecuteStmt *a, const ExecuteStmt *b)
{
COMPARE_STRING_FIELD(name);
- COMPARE_NODE_FIELD(into);
COMPARE_NODE_FIELD(params);
return true;
@@ -2812,6 +2821,9 @@ equal(const void *a, const void *b)
case T_ExplainStmt:
retval = _equalExplainStmt(a, b);
break;
+ case T_CreateTableAsStmt:
+ retval = _equalCreateTableAsStmt(a, b);
+ break;
case T_CreateSeqStmt:
retval = _equalCreateSeqStmt(a, b);
break;
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index 25a215e..9cb8592 100644
--- a/src/backend/nodes/outfuncs.c
+++ b/src/backend/nodes/outfuncs.c
@@ -248,7 +248,6 @@ _outPlannedStmt(StringInfo str, const PlannedStmt *node)
WRITE_NODE_FIELD(rtable);
WRITE_NODE_FIELD(resultRelations);
WRITE_NODE_FIELD(utilityStmt);
- WRITE_NODE_FIELD(intoClause);
WRITE_NODE_FIELD(subplans);
WRITE_BITMAPSET_FIELD(rewindPlanIDs);
WRITE_NODE_FIELD(rowMarks);
@@ -2187,7 +2186,6 @@ _outQuery(StringInfo str, const Query *node)
appendStringInfo(str, " :utilityStmt <>");
WRITE_INT_FIELD(resultRelation);
- WRITE_NODE_FIELD(intoClause);
WRITE_BOOL_FIELD(hasAggs);
WRITE_BOOL_FIELD(hasWindowFuncs);
WRITE_BOOL_FIELD(hasSubLinks);
@@ -2805,7 +2803,7 @@ _outNode(StringInfo str, const void *obj)
case T_RangeVar:
_outRangeVar(str, obj);
break;
- case T_IntoClause:
+ case T_IntoClause:/*XXX: This could be removed but dim would need to add it right back*/
_outIntoClause(str, obj);
break;
case T_Var:
diff --git a/src/backend/nodes/readfuncs.c b/src/backend/nodes/readfuncs.c
index 1d78cfd..0b596f0 100644
--- a/src/backend/nodes/readfuncs.c
+++ b/src/backend/nodes/readfuncs.c
@@ -198,7 +198,6 @@ _readQuery(void)
READ_BOOL_FIELD(canSetTag);
READ_NODE_FIELD(utilityStmt);
READ_INT_FIELD(resultRelation);
- READ_NODE_FIELD(intoClause);
READ_BOOL_FIELD(hasAggs);
READ_BOOL_FIELD(hasWindowFuncs);
READ_BOOL_FIELD(hasSubLinks);
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 8bbe977..6b0541b 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -233,7 +233,6 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->rtable = glob->finalrtable;
result->resultRelations = glob->resultRelations;
result->utilityStmt = parse->utilityStmt;
- result->intoClause = parse->intoClause;
result->subplans = glob->subplans;
result->rewindPlanIDs = glob->rewindPlanIDs;
result->rowMarks = glob->finalrowmarks;
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 40a420a..8006787 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -1399,7 +1399,6 @@ simplify_EXISTS_query(Query *query)
* are complex.
*/
if (query->commandType != CMD_SELECT ||
- query->intoClause ||
query->setOperations ||
query->hasAggs ||
query->hasWindowFuncs ||
diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
index 59a5268..0304c9d 100644
--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -1129,8 +1129,7 @@ is_simple_subquery(Query *subquery)
*/
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/*
@@ -1216,8 +1215,7 @@ is_simple_union_all(Query *subquery)
/* Let's just make sure it's a valid subselect ... */
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/* Is it a set-operation query at all? */
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index cd3da46..7d40e3e 100644
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -4168,7 +4168,6 @@ inline_function(Oid funcid, Oid result_type, Oid result_collid,
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
querytree->utilityStmt ||
- querytree->intoClause ||
querytree->hasAggs ||
querytree->hasWindowFuncs ||
querytree->hasSubLinks ||
@@ -4682,8 +4681,7 @@ inline_set_returning_function(PlannerInfo *root, RangeTblEntry *rte)
*/
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
- querytree->utilityStmt ||
- querytree->intoClause)
+ querytree->utilityStmt)
goto fail;
/*
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index b187b03..182d6f7 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -62,6 +62,8 @@ static Query *transformDeclareCursorStmt(ParseState *pstate,
DeclareCursorStmt *stmt);
static Query *transformExplainStmt(ParseState *pstate,
ExplainStmt *stmt);
+static Query *transformCreateTableAsStmt(ParseState *pstate,
+ CreateTableAsStmt *stmt);
static void transformLockingClause(ParseState *pstate, Query *qry,
LockingClause *lc, bool pushedDown);
@@ -202,6 +204,11 @@ transformStmt(ParseState *pstate, Node *parseTree)
(ExplainStmt *) parseTree);
break;
+ case T_CreateTableAsStmt:
+ result = transformCreateTableAsStmt(pstate,
+ (CreateTableAsStmt *) parseTree);
+ break;
+
default:
/*
@@ -257,6 +264,7 @@ analyze_requires_snapshot(Node *parseTree)
result = true;
break;
+ case T_CreateTableAsStmt:
case T_ExplainStmt:
/* yes, because we must analyze the contained statement */
result = true;
@@ -455,21 +463,29 @@ transformInsertStmt(ParseState *pstate, InsertStmt *stmt)
sub_pstate->p_relnamespace = sub_relnamespace;
sub_pstate->p_varnamespace = sub_varnamespace;
+ /* The grammar should have produced a SELECT, but it might have INTO */
+ if(IsA(stmt->selectStmt, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->selectStmt;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INSERT ... SELECT cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
selectQuery = transformStmt(sub_pstate, stmt->selectStmt);
free_parsestate(sub_pstate);
- /* The grammar should have produced a SELECT, but it might have INTO */
if (!IsA(selectQuery, Query) ||
selectQuery->commandType != CMD_SELECT ||
selectQuery->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in INSERT ... SELECT");
- if (selectQuery->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("INSERT ... SELECT cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) selectQuery->intoClause))));
/*
* Make the source be a subquery in the INSERT's rangetable, and add
@@ -876,6 +892,18 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
Node *qual;
ListCell *l;
+ /*
+ * Validity-check whether we got called from somewhere where
+ * ... INTO was not allowed
+ */
+ if (stmt->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INTO is only allowed on first SELECT of UNION/INTERSECT/EXCEPT"),
+ parser_errposition(pstate,
+ exprLocation((Node *) stmt->intoClause))));
+
+
qry->commandType = CMD_SELECT;
/* process the WITH clause independently of all else */
@@ -963,8 +991,6 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
pstate->p_windowdefs,
&qry->targetList);
- /* SELECT INTO/CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
qry->rtable = pstate->p_rtable;
qry->jointree = makeFromExpr(pstate->p_joinlist, qual);
@@ -1185,9 +1211,6 @@ transformValuesClause(ParseState *pstate, SelectStmt *stmt)
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("SELECT FOR UPDATE/SHARE cannot be applied to VALUES")));
- /* CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
-
/*
* There mustn't have been any table references in the expressions, else
* strange things would happen, like Cartesian products of those tables
@@ -1253,7 +1276,6 @@ static Query *
transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
{
Query *qry = makeNode(Query);
- SelectStmt *leftmostSelect;
int leftmostRTI;
Query *leftmostQuery;
SetOperationStmt *sostmt;
@@ -1286,20 +1308,6 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
}
/*
- * Find leftmost leaf SelectStmt; extract the one-time-only items from it
- * and from the top-level node.
- */
- leftmostSelect = stmt->larg;
- while (leftmostSelect && leftmostSelect->op != SETOP_NONE)
- leftmostSelect = leftmostSelect->larg;
- Assert(leftmostSelect && IsA(leftmostSelect, SelectStmt) &&
- leftmostSelect->larg == NULL);
- qry->intoClause = leftmostSelect->intoClause;
-
- /* clear this to prevent complaints in transformSetOperationTree() */
- leftmostSelect->intoClause = NULL;
-
- /*
* These are not one-time, exactly, but we want to process them here and
* not let transformSetOperationTree() see them --- else it'll just
* recurse right back here!
@@ -1330,7 +1338,7 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
qry->setOperations = (Node *) sostmt;
/*
- * Re-find leftmost SELECT (now it's a sub-query in rangetable)
+ * Find leftmost SELECT (it's a sub-query in rangetable)
*/
node = sostmt->larg;
while (node && IsA(node, SetOperationStmt))
@@ -2099,6 +2107,25 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
(errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
errmsg("cannot specify both SCROLL and NO SCROLL")));
+ /*
+ * We must explicitly disallow DECLARE CURSOR ... SELECT INTO We
+ * have to do this before transformStmt() as that will holler if
+ * it ever finds a intoClause
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
+ errmsg("DECLARE CURSOR cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
result = transformStmt(pstate, stmt->query);
/* Grammar should not have allowed anything but SELECT */
@@ -2107,14 +2134,6 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
result->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in DECLARE CURSOR");
- /* But we must explicitly disallow DECLARE CURSOR ... SELECT INTO */
- if (result->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
- errmsg("DECLARE CURSOR cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) result->intoClause))));
-
/*
* We also disallow data-modifying WITH in a cursor. (This could be
* allowed, but the semantics of when the updates occur might be
@@ -2183,6 +2202,28 @@ transformExplainStmt(ParseState *pstate, ExplainStmt *stmt)
/*
+ * transformCreateTableAsStmt -
+ * transform an CREATE TABLE AS/SELECT ... INTO Statement
+ *
+ */
+static Query *
+transformCreateTableAsStmt(ParseState *pstate, CreateTableAsStmt *stmt)
+{
+ Query *result;
+
+ /* transform contained query */
+ stmt->query = (Node *) transformStmt(pstate, stmt->query);
+
+ /* represent the command as a utility Query */
+ result = makeNode(Query);
+ result->commandType = CMD_UTILITY;
+ result->utilityStmt = (Node *) stmt;
+
+ return result;
+}
+
+
+/*
* Check for features that are not supported together with FOR UPDATE/SHARE.
*
* exported so planner can check again after rewriting, query pullup, etc
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index e9872d3..553dfc9 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -3058,23 +3058,28 @@ ExistingIndex: USING INDEX index_name { $$ = $3; }
CreateAsStmt:
CREATE OptTemp TABLE create_as_target AS SelectStmt opt_with_data
{
+ SelectStmt *n;
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = $4;
+ ctas->query = $6;
+ ctas->is_select_into = false;
+ $4->skipData = !($7);
+ $4->rel->relpersistence = $2;
+ $4->skipData = !($7);
+ $$ = (Node*)ctas;
+
/*
* When the SelectStmt is a set-operation tree, we must
* stuff the INTO information into the leftmost component
* Select, because that's where analyze.c will expect
* to find it.
*/
- SelectStmt *n = findLeftmostSelect((SelectStmt *) $6);
+ n = findLeftmostSelect((SelectStmt *) $6);
if (n->intoClause != NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("CREATE TABLE AS cannot specify INTO"),
parser_errposition(exprLocation((Node *) n->intoClause))));
- n->intoClause = $4;
- /* cram additional flags into the IntoClause */
- $4->rel->relpersistence = $2;
- $4->skipData = !($7);
- $$ = $6;
}
;
@@ -8451,20 +8456,25 @@ ExecuteStmt: EXECUTE name execute_param_clause
ExecuteStmt *n = makeNode(ExecuteStmt);
n->name = $2;
n->params = $3;
- n->into = NULL;
$$ = (Node *) n;
}
| CREATE OptTemp TABLE create_as_target AS
EXECUTE name execute_param_clause opt_with_data
{
ExecuteStmt *n = makeNode(ExecuteStmt);
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+
n->name = $7;
n->params = $8;
- n->into = $4;
+
/* cram additional flags into the IntoClause */
$4->rel->relpersistence = $2;
$4->skipData = !($9);
- $$ = (Node *) n;
+
+ ctas->into = $4;
+ ctas->query = (Node*)n;
+ ctas->is_select_into = false;
+ $$ = (Node *) ctas;
}
;
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 7f4da92..52f449f 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -481,6 +481,21 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
if (r->alias == NULL)
elog(ERROR, "subquery in FROM must have an alias");
+
+ if(IsA(r->subquery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)r->subquery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in FROM cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
/*
* Analyze and transform the subquery.
*/
@@ -495,12 +510,6 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
query->commandType != CMD_SELECT ||
query->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in subquery in FROM");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in FROM cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
/*
* The subquery cannot make use of any variables from FROM items created
diff --git a/src/backend/parser/parse_cte.c b/src/backend/parser/parse_cte.c
index c0c6240..4ea8ee6 100644
--- a/src/backend/parser/parse_cte.c
+++ b/src/backend/parser/parse_cte.c
@@ -241,6 +241,20 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
/* Analysis not done already */
Assert(!IsA(cte->ctequery, Query));
+ if(IsA(cte->ctequery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)cte->ctequery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in WITH cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
query = parse_sub_analyze(cte->ctequery, pstate, cte, false);
cte->ctequery = (Node *) query;
@@ -253,13 +267,6 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
if (query->utilityStmt != NULL)
elog(ERROR, "unexpected utility statement in WITH");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in WITH cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
-
/*
* We disallow data-modifying WITH except at the top level of a query,
* because it's not clear when such a modification should be executed.
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index d22d8a1..d4d9121 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1398,6 +1398,21 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
return result;
pstate->p_hasSubLinks = true;
+
+ if(IsA(sublink->subselect, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)sublink->subselect;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
qtree = parse_sub_analyze(sublink->subselect, pstate, NULL, false);
/*
@@ -1408,12 +1423,6 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
qtree->commandType != CMD_SELECT ||
qtree->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in SubLink");
- if (qtree->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) qtree->intoClause))));
sublink->subselect = (Node *) qtree;
diff --git a/src/backend/parser/parser.c b/src/backend/parser/parser.c
index f9ec2b2..854925c 100644
--- a/src/backend/parser/parser.c
+++ b/src/backend/parser/parser.c
@@ -37,6 +37,7 @@ raw_parser(const char *str)
core_yyscan_t yyscanner;
base_yy_extra_type yyextra;
int yyresult;
+ ListCell *c;
/* initialize the flex scanner */
yyscanner = scanner_init(str, &yyextra.core_yy_extra,
@@ -57,6 +58,43 @@ raw_parser(const char *str)
if (yyresult) /* error */
return NIL;
+ /*
+ * Some things are rather hard to properly diagnose in grammar
+ * without complicating/duplicating it too much. So we do some
+ * postprocessing here.
+ */
+ foreach(c, yyextra.parsetree){
+ switch(nodeTag(lfirst(c))){
+ /*
+ * The grammar currently doesn't disambiguate between
+ * SELECT and SELECT ... INTO. Do that now.
+ */
+ case T_SelectStmt:
+ {
+ SelectStmt* s = (SelectStmt*)lfirst(c);
+ SelectStmt* first = s;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+ Assert(first && IsA(first, SelectStmt) && first->larg == NULL);
+ if(first->intoClause){
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = first->intoClause;
+ ctas->query = (Node*)s;
+ ctas->is_select_into = true;
+ /*
+ * this way everyone can complain if this is set
+ * without further checks because it shall never
+ * be set but here.
+ */
+ first->intoClause = NULL;
+ lfirst(c) = ctas;
+ break;
+ }
+ }
+ default:
+ break;
+ }
+ }
return yyextra.parsetree;
}
diff --git a/src/backend/rewrite/rewriteDefine.c b/src/backend/rewrite/rewriteDefine.c
index 03c1296..eff4c75 100644
--- a/src/backend/rewrite/rewriteDefine.c
+++ b/src/backend/rewrite/rewriteDefine.c
@@ -329,8 +329,7 @@ DefineQueryRewrite(char *rulename,
query = (Query *) linitial(action);
if (!is_instead ||
query->commandType != CMD_SELECT ||
- query->utilityStmt != NULL ||
- query->intoClause != NULL)
+ query->utilityStmt != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("rules on SELECT must have action INSTEAD SELECT")));
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 42a0fb0..7c50284 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -260,8 +260,7 @@ ChoosePortalStrategy(List *stmts)
if (query->canSetTag)
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
{
if (query->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -285,8 +284,7 @@ ChoosePortalStrategy(List *stmts)
if (pstmt->canSetTag)
{
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
{
if (pstmt->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -395,8 +393,7 @@ FetchStatementTargetList(Node *stmt)
else
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
return query->targetList;
if (query->returningList)
return query->returningList;
@@ -408,8 +405,7 @@ FetchStatementTargetList(Node *stmt)
PlannedStmt *pstmt = (PlannedStmt *) stmt;
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
return pstmt->planTree->targetlist;
if (pstmt->hasReturning)
return pstmt->planTree->targetlist;
@@ -430,7 +426,6 @@ FetchStatementTargetList(Node *stmt)
ExecuteStmt *estmt = (ExecuteStmt *) stmt;
PreparedStatement *entry;
- Assert(!estmt->into);
entry = FetchPreparedStatement(estmt->name, true);
return FetchPreparedStatementTargetList(entry);
}
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 69d6479..61ce5a6 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -128,9 +128,7 @@ CommandIsReadOnly(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- return false; /* SELECT INTO */
- else if (stmt->rowMarks != NIL)
+ if (stmt->rowMarks != NIL)
return false; /* SELECT FOR UPDATE/SHARE */
else if (stmt->hasModifyingCTE)
return false; /* data-modifying CTE */
@@ -383,6 +381,7 @@ check_xact_readonly(Node *parsetree)
case T_CreateSchemaStmt:
case T_CreateSeqStmt:
case T_CreateStmt:
+ case T_CreateTableAsStmt:
case T_CreateTableSpaceStmt:
case T_CreateTrigStmt:
case T_CompositeTypeStmt:
@@ -1299,6 +1298,10 @@ standard_ProcessUtility(Node *parsetree,
ExplainQuery((ExplainStmt *) parsetree, queryString, params, dest);
break;
+ case T_CreateTableAsStmt:
+ CreateTableAs((CreateTableAsStmt *) parsetree, queryString, params, dest);
+ break;
+
case T_VariableSetStmt:
ExecSetVariableStmt((VariableSetStmt *) parsetree);
break;
@@ -1507,8 +1510,6 @@ UtilityReturnsTuples(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return false;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return false; /* not our business to raise error */
@@ -1559,8 +1560,6 @@ UtilityTupleDescriptor(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return NULL;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return NULL; /* not our business to raise error */
@@ -1595,8 +1594,7 @@ QueryReturnsTuples(Query *parsetree)
{
case CMD_SELECT:
/* returns tuples ... unless it's DECLARE CURSOR or SELECT INTO */
- if (parsetree->utilityStmt == NULL &&
- parsetree->intoClause == NULL)
+ if (parsetree->utilityStmt == NULL)
return true;
break;
case CMD_INSERT:
@@ -2187,6 +2185,13 @@ CreateCommandTag(Node *parsetree)
tag = "EXPLAIN";
break;
+ case T_CreateTableAsStmt:
+ if (((CreateTableAsStmt*)parsetree)->is_select_into)
+ tag = "SELECT INTO";
+ else
+ tag = "CREATE TABLE AS";
+ break;
+
case T_VariableSetStmt:
switch (((VariableSetStmt *) parsetree)->kind)
{
@@ -2348,8 +2353,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2398,8 +2401,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2473,10 +2474,7 @@ GetCommandLogLevel(Node *parsetree)
break;
case T_SelectStmt:
- if (((SelectStmt *) parsetree)->intoClause)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL;
+ lev = LOGSTMT_ALL;
break;
/* utility statements --- same whether raw or cooked */
@@ -2724,6 +2722,10 @@ GetCommandLogLevel(Node *parsetree)
}
break;
+ case T_CreateTableAsStmt:
+ lev = LOGSTMT_DDL;
+ break;
+
case T_VariableSetStmt:
lev = LOGSTMT_ALL;
break;
@@ -2836,10 +2838,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
@@ -2865,10 +2864,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
diff --git a/src/include/access/htup.h b/src/include/access/htup.h
index 6a3778d..abbc152 100644
--- a/src/include/access/htup.h
+++ b/src/include/access/htup.h
@@ -311,7 +311,7 @@ do { \
#define HeapTupleHeaderSetOid(tup, oid) \
do { \
- Assert((tup)->t_infomask & HEAP_HASOID); \
+ if(!((tup)->t_infomask & HEAP_HASOID)) elog(ERROR, "HEAP_HASOID"); \
*((Oid *) ((char *)(tup) + (tup)->t_hoff - sizeof(Oid))) = (oid); \
} while (0)
diff --git a/src/include/commands/prepare.h b/src/include/commands/prepare.h
index 472a357..6b545dc 100644
--- a/src/include/commands/prepare.h
+++ b/src/include/commands/prepare.h
@@ -54,4 +54,7 @@ extern List *FetchPreparedStatementTargetList(PreparedStatement *stmt);
void DropAllPreparedStatements(void);
+extern ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
+ const char *queryString, EState *estate);
+
#endif /* PREPARE_H */
diff --git a/src/include/commands/tablecmds.h b/src/include/commands/tablecmds.h
index 2e0b1f1..e8efce1 100644
--- a/src/include/commands/tablecmds.h
+++ b/src/include/commands/tablecmds.h
@@ -16,6 +16,7 @@
#include "access/htup.h"
#include "commands/cmdtrigger.h"
+#include "executor/executor.h"
#include "nodes/parsenodes.h"
#include "storage/lock.h"
#include "utils/relcache.h"
@@ -23,6 +24,9 @@
extern Oid DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId);
+extern void CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest);
+
extern void RemoveRelations(DropStmt *drop);
extern Oid AlterTableLookupRelation(AlterTableStmt *stmt, LOCKMODE lockmode);
diff --git a/src/include/executor/executor.h b/src/include/executor/executor.h
index 7f27669..47bd1ee 100644
--- a/src/include/executor/executor.h
+++ b/src/include/executor/executor.h
@@ -49,12 +49,17 @@
* AfterTriggerBeginQuery/AfterTriggerEndQuery. This does not necessarily
* mean that the plan can't queue any AFTER triggers; just that the caller
* is responsible for there being a trigger context for them to be queued in.
+ *
+ * FORCE_OIDS tells the executor to build a tupleDesc that includes
+ * the oid column. This is used from tablecmd.c's CreateTableAs.
*/
#define EXEC_FLAG_EXPLAIN_ONLY 0x0001 /* EXPLAIN, no ANALYZE */
#define EXEC_FLAG_REWIND 0x0002 /* need efficient rescan */
#define EXEC_FLAG_BACKWARD 0x0004 /* need backward scan */
#define EXEC_FLAG_MARK 0x0008 /* need mark/restore */
#define EXEC_FLAG_SKIP_TRIGGERS 0x0010 /* skip AfterTrigger calls */
+#define EXEC_FLAG_FORCE_OIDS_ON 0x0020 /* force oids in returned tuples */
+#define EXEC_FLAG_FORCE_OIDS_OFF 0x0040 /* force oids in returned tuples */
/*
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 5207102..d268fb9 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -322,6 +322,12 @@ typedef struct ResultRelInfo
ProjectionInfo *ri_projectReturning;
} ResultRelInfo;
+typedef enum {
+ ESTATE_FORCE_OIDS_DEFAULT,
+ ESTATE_FORCE_OIDS_ON,
+ ESTATE_FORCE_OIDS_OFF
+} EStateForceOids;
+
/* ----------------
* EState information
*
@@ -371,8 +377,7 @@ typedef struct EState
int es_top_eflags; /* eflags passed to ExecutorStart */
int es_instrument; /* OR of InstrumentOption flags */
- bool es_select_into; /* true if doing SELECT INTO */
- bool es_into_oids; /* true to generate OIDs in SELECT INTO */
+ EStateForceOids es_force_oids; /* used by CreateTableAs */
bool es_finished; /* true when ExecutorFinish is done */
List *es_exprcontexts; /* List of ExprContexts within EState */
diff --git a/src/include/nodes/nodes.h b/src/include/nodes/nodes.h
index 1b7298a..9a260c7 100644
--- a/src/include/nodes/nodes.h
+++ b/src/include/nodes/nodes.h
@@ -305,6 +305,7 @@ typedef enum NodeTag
T_DropdbStmt,
T_VacuumStmt,
T_ExplainStmt,
+ T_CreateTableAsStmt,
T_CreateSeqStmt,
T_AlterSeqStmt,
T_VariableSetStmt,
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index d4d1333..433cbc8 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -111,8 +111,6 @@ typedef struct Query
int resultRelation; /* rtable index of target relation for
* INSERT/UPDATE/DELETE; 0 for SELECT */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
bool hasAggs; /* has aggregates in tlist or havingQual */
bool hasWindowFuncs; /* has window functions in tlist */
bool hasSubLinks; /* has subquery SubLink */
@@ -1009,7 +1007,7 @@ typedef struct SelectStmt
*/
List *distinctClause; /* NULL, list of DISTINCT ON exprs, or
* lcons(NIL,NIL) for all (SELECT DISTINCT) */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
+ IntoClause *intoClause; /* target for SELECT INTO */
List *targetList; /* the target list (of ResTarget) */
List *fromClause; /* the FROM clause */
Node *whereClause; /* WHERE qualification */
@@ -2430,7 +2428,7 @@ typedef struct VacuumStmt
* Explain Statement
*
* The "query" field is either a raw parse tree (SelectStmt, InsertStmt, etc)
- * or a Query node if parse analysis has been done. Note that rewriting and
+ * or a Query node if parse analysis has been done. Note that rewriting and
* planning of the query are always postponed until execution of EXPLAIN.
* ----------------------
*/
@@ -2442,6 +2440,19 @@ typedef struct ExplainStmt
} ExplainStmt;
/* ----------------------
+ * analyzing, rewriting and planning are handled as in explain
+ * statements (see comment above) only that query can only be a
+ * SelectStmt and not some other type.
+ */
+typedef struct CreateTableAsStmt
+{
+ NodeTag type;
+ IntoClause *into;
+ Node *query; /* the query (see comments above) */
+ bool is_select_into; /* plpgsql wants to disambiguate */
+} CreateTableAsStmt;
+
+/* ----------------------
* Checkpoint Statement
* ----------------------
*/
@@ -2555,7 +2566,6 @@ typedef struct ExecuteStmt
{
NodeTag type;
char *name; /* The name of the plan to execute */
- IntoClause *into; /* Optional table to store results in */
List *params; /* Values to assign to parameters */
} ExecuteStmt;
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 7d90b91..b67d988 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -54,8 +54,6 @@ typedef struct PlannedStmt
Node *utilityStmt; /* non-null if this is DECLARE CURSOR */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
List *subplans; /* Plan trees for SubPlan expressions */
Bitmapset *rewindPlanIDs; /* indices of subplans that require REWIND */
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 0b126a3..231210a 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -3286,29 +3286,18 @@ exec_stmt_dynexecute(PLpgSQL_execstate *estate,
break;
case SPI_OK_SELINTO:
-
/*
* We want to disallow SELECT INTO for now, because its behavior
* is not consistent with SELECT INTO in a normal plpgsql context.
* (We need to reimplement EXECUTE to parse the string as a
* plpgsql command, not just feed it to SPI_execute.) However,
- * CREATE AS should be allowed ... and since it produces the same
- * parsetree as SELECT INTO, there's no way to tell the difference
- * except to look at the source text. Wotta kluge!
+ * CREATE AS should be allowed ...
*/
- {
- char *ptr;
-
- for (ptr = querystr; *ptr; ptr++)
- if (!scanner_isspace(*ptr))
- break;
- if (*ptr == 'S' || *ptr == 's')
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("EXECUTE of SELECT ... INTO is not implemented"),
- errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
- break;
- }
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("EXECUTE of SELECT ... INTO is not implemented"),
+ errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
+ break;
/* Some SPI errors deserve specific error messages */
case SPI_ERROR_COPY:
@@ -5759,7 +5748,7 @@ exec_simple_check_plan(PLpgSQL_expr *expr)
*/
if (!IsA(query, Query))
return;
- if (query->commandType != CMD_SELECT || query->intoClause)
+ if (query->commandType != CMD_SELECT)
return;
if (query->rtable != NIL)
return;
@@ -5833,7 +5822,7 @@ exec_simple_recheck_plan(PLpgSQL_expr *expr, CachedPlan *cplan)
*/
if (!IsA(stmt, PlannedStmt))
return;
- if (stmt->commandType != CMD_SELECT || stmt->intoClause)
+ if (stmt->commandType != CMD_SELECT)
return;
plan = stmt->planTree;
if (!IsA(plan, Result))
diff --git a/src/test/regress/expected/select_into.out b/src/test/regress/expected/select_into.out
index c8327f6..d124382 100644
--- a/src/test/regress/expected/select_into.out
+++ b/src/test/regress/expected/select_into.out
@@ -44,6 +44,25 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
AS SELECT oid,relname,relacl FROM pg_class
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ERROR: DECLARE CURSOR cannot specify INTO
+LINE 1: DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ ^
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+ERROR: COPY (SELECT INTO) is not supported
+SELECT * FROM (SELECT 1 INTO f) bar;
+ERROR: subquery in FROM cannot have SELECT INTO
+LINE 1: SELECT * FROM (SELECT 1 INTO f) bar;
+ ^
+CREATE VIEW foo AS SELECT 1 INTO b;
+ERROR: views must not contain SELECT INTO
+INSERT INTO b SELECT 1 INTO f;
+ERROR: INSERT ... SELECT cannot specify INTO
+LINE 1: INSERT INTO b SELECT 1 INTO f;
+ ^
DROP SCHEMA selinto_schema CASCADE;
NOTICE: drop cascades to 3 other objects
DETAIL: drop cascades to table selinto_schema.tmp1
diff --git a/src/test/regress/expected/transactions.out b/src/test/regress/expected/transactions.out
index e9d3908..6981692 100644
--- a/src/test/regress/expected/transactions.out
+++ b/src/test/regress/expected/transactions.out
@@ -139,7 +139,7 @@ SELECT * FROM writetest, temptest; -- ok
(0 rows)
CREATE TABLE test AS SELECT * FROM writetest; -- fail
-ERROR: cannot execute SELECT INTO in a read-only transaction
+ERROR: cannot execute CREATE TABLE AS in a read-only transaction
START TRANSACTION READ WRITE;
DROP TABLE writetest; -- ok
COMMIT;
diff --git a/src/test/regress/sql/select_into.sql b/src/test/regress/sql/select_into.sql
index 09d210b..0c07f76 100644
--- a/src/test/regress/sql/select_into.sql
+++ b/src/test/regress/sql/select_into.sql
@@ -50,6 +50,21 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+
+SELECT * FROM (SELECT 1 INTO f) bar;
+
+CREATE VIEW foo AS SELECT 1 INTO b;
+
+INSERT INTO b SELECT 1 INTO f;
+
+
DROP SCHEMA selinto_schema CASCADE;
DROP USER selinto_user;
--
1.7.9
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-05 00:33 ` Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-05 00:33 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 4 March 2012 15:50, Andres Freund <andres@anarazel.de> wrote:
> Ok, I rebased my patch ontop of dim's current HEAD. There was only one trivial
> conflict in tablecmds.h. I had written the patch independently of the command
> triggers stuff because I though, and still do, that would make applying it
> easier.
>
> Attached are two versions of the patch, one based on command triggers and one
> without. Both pass regression tests for me.
I have conducted testing against Dimitri’s latest patch, along with
the incremental patch to fix the build, and also Andres’ CTAS patch.
I've attached a copy of how I configured the command triggers
(command_trigger_test_setup.txt), and also the set of tests I've been
running against the changes (command_trigger_regression.sql). I've
left comments in that last file where I haven't been able to conduct a
test for particular commands.
Creating a command trigger using ANY COMMAND results in oid,
schemaname, objectname (function parameters 4 & 5) not being set for
either BEFORE or AFTER.
There is no support for ALTER CONVERSION.
When trying to create an AFTER command trigger on CREATE INDEX, I get
the warning:
WARNING: CREATE INDEX CONCURRENTLY is not supported
DETAIL: The command trigger will not get fired.
This should probably say that it’s not supported on AFTER command
triggers yet rather than the general DDL itself.
Command triggers for AFTER creating rules don’t return OIDs.
thom@test=# CREATE RULE "_RETURN" AS
ON SELECT TO test2
DO INSTEAD
SELECT 234 id, 'test'::text stuff;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
RULE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE RULE'
objectid=<NULL> schemaname='public' objectname='_RETURN'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE RULE'
objectid=<NULL> schemaname='public' objectname='_RETURN'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE RULE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
CREATE RULE
Command triggers for creating sequences don’t show the schema:
thom@test=# CREATE TEMP SEQUENCE test_seq2;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE SEQUENCE'
objectid=<NULL> schemaname='<NULL>' objectname='test_seq2'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE SEQUENCE'
objectid=25130 schemaname='<NULL>' objectname='test_seq2'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
CREATE SEQUENCE
Command triggers for AFTER creating extensions with IF NOT EXISTS
don’t fire, but do in the ANY COMMAND instance:
thom@test=# CREATE EXTENSION IF NOT EXISTS file_fdw;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE EXTENSION'
objectid=<NULL> schemaname='<NULL>' objectname='file_fdw'
NOTICE: extension "file_fdw" already exists, skipping
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
CREATE EXTENSION
Command triggers on CREATE TEXT SEARCH DICTIONARY show the name as garbage:
thom@test=# CREATE TEXT SEARCH DICTIONARY test_stem (
test(# TEMPLATE = snowball,
test(# language = 'english', stopwords = 'english'
test(# );
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE TEXT
SEARCH DICTIONARY' objectid=<NULL> schemaname='<NULL>'
objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE TEXT SEARCH
DICTIONARY' objectid=<NULL> schemaname='thom' objectname='�Ч�l '
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE TEXT SEARCH
DICTIONARY' objectid=25139 schemaname='thom' objectname='�Ч�l '
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE TEXT
SEARCH DICTIONARY' objectid=<NULL> schemaname='<NULL>'
objectname='<NULL>'
CREATE TEXT SEARCH DICTIONARY
Command triggers for BEFORE CREATE TYPE (exluding ANY COMMAND) don’t
fire if the type isn’t created due to an error:
thom@test=# CREATE TYPE thom.type_test AS
(a integer,
b integer,
c text);
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
TYPE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ERROR: type "type_test" already exists
The ANY COMMAND trigger fires on creating roles, but there’s no
corresponding allowance to create the trigger explicitly for creating
roles.
Command triggers for AFTER CREATE VIEW don’t show the schema:
thom@test=# CREATE VIEW view_test AS SELECT id, stuff FROM public.test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
VIEW' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='view_test'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE VIEW'
objectid=25155 schemaname='<NULL>' objectname='view_test'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
CREATE VIEW
Command triggers for BEFORE and AFTER ALTER DOMAIN show a garbage name
and no schema when dropping a constraint:
thom@test=# ALTER DOMAIN us_postal_code DROP CONSTRAINT dummy_constraint;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER DOMAIN'
objectid=25085 schemaname='<NULL>' objectname='�'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER DOMAIN'
objectid=25085 schemaname='<NULL>' objectname='�'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER DOMAIN
Continuing with this same trigger, we do get a schema but a garbage
name for OWNER TO:
thom@test=# ALTER DOMAIN us_postal_code OWNER TO test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER DOMAIN'
objectid=25085 schemaname='public' objectname='�'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER DOMAIN'
objectid=25085 schemaname='public' objectname='�'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER DOMAIN
When an ALTER EXTENSION fails to upgrade, the AFTER ANY COMMAND
trigger fires, but not command triggers specifically for ALTER
EXTENSION:
thom@test=# ALTER EXTENSION file_fdw UPDATE TO '1.0';
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER EXTENSION'
objectid=25087 schemaname='<NULL>' objectname='file_fdw'
NOTICE: version "1.0" of extension "file_fdw" is already installed
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER EXTENSION
Same on ALTER EXTENSION, when failing to add a member, the BEFORE ANY
COMMAND trigger fires, but not the one specifically for ALTER
EXTENSION:
thom@test=# ALTER EXTENSION file_fdw ADD COLLATION en_gb_test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ERROR: collation "en_gb_test" for encoding "UTF8" does not exist
Specific command triggers against ALTER FOREIGN TABLE (i.e. not ANY
COMMAND) for BEFORE and AFTER aren’t working when renaming columns:
thom@test=# ALTER FOREIGN TABLE test.dict2 RENAME COLUMN word TO words;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
TABLE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER TABLE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER TABLE
Specific command triggers agains ALTER FUNCTION (i.e. not ANY COMMAND)
don’t fire for any changes except renaming, changing owner or changing
schema. Everything else fails to trigger (cost, rows, setting
configuration parameters, setting strict, security invoker etc.).:
thom@test=# ALTER FUNCTION test.testfunc2() COST 77;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER FUNCTION
thom@test=# ALTER FUNCTION srf_test() ROWS 5;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER FUNCTION
thom@test=# ALTER FUNCTION srf_test() RESET ALL;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER FUNCTION
thom@test=# ALTER FUNCTION srf_test() SET work_mem TO '1MB';
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER FUNCTION
There doesn’t appear to be command trigger support for ALTER LARGE OBJECT.
Specific command triggers on ALTER SEQUENCE don’t fire:
thom@test=# ALTER SEQUENCE test_seq OWNER TO test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER SEQUENCE
Specific command triggers on ALTER TABLE don’t fire for renaming columns:
thom@test=# ALTER TABLE testnew.test9 RENAME COLUMN stuff TO things;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
TABLE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER TABLE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER TABLE
Command triggers on ALTER TYPE when changing owner produce a garbage name:
thom@test=# ALTER TYPE testnew.type_test OWNER TO test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER TYPE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER TYPE'
objectid=25170 schemaname='testnew' objectname='�'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER TYPE'
objectid=25170 schemaname='testnew' objectname='�'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER TYPE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER TYPE
Also renaming attributes doesn’t fire specific triggers:
thom@test=# ALTER TYPE public.type_test2 RENAME ATTRIBUTE a TO z;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER TYPE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER TYPE'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER TYPE
Specific command triggers on ALTER VIEW don’t fire for any type of change:
thom@test=# ALTER VIEW view_test OWNER TO test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER VIEW
thom@test=# ALTER VIEW testnew.view_test2 ALTER COLUMN id SET DEFAULT 9;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER VIEW
Specific command triggers on DROP AGGREGATE don’t fire in the IF
EXISTS scenario if the target object doesn’t exist:
thom@test=# DROP AGGREGATE IF EXISTS avgtest2(bigint);
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: aggregate avgtest2(pg_catalog.int8) does not exist, skipping
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP AGGREGATE
This appears to be a general thing, as the same occurs for DROP CAST
IF EXISTS and DROP COLLATION IF EXISTS. These do, however, fire if
the object does exist.
When adding objects to an extension, then dropping the extension with
a cascade, the objects are dropped with it, but triggers aren’t fired
to the removal of those dependant objects:
thom@test=# ALTER EXTENSION file_fdw ADD TABLE dep_test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER EXTENSION'
objectid=25207 schemaname='<NULL>' objectname='file_fdw'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER EXTENSION'
objectid=25207 schemaname='<NULL>' objectname='file_fdw'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER EXTENSION
thom@test=# DROP EXTENSION file_fdw CASCADE;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP EXTENSION'
objectid=25207 schemaname='<NULL>' objectname='file_fdw'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP EXTENSION'
objectid=<NULL> schemaname='<NULL>' objectname='file_fdw'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
EXTENSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP EXTENSION
Using DROP OWNED BY allows objects to be dropped without their
respective specific triggers firing.
thom@test=# \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+-----------
thom | role_test_table | table | role_test
thom | seq_table | table | test
(2 rows)
thom@test=# DROP OWNED BY role_test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP OWNED'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP OWNED'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP OWNED
Using DROP SCHEMA … CASACDE also allows objects to be dropped without
their respective specific triggers firing:
thom@test=# DROP SCHEMA test6 CASCADE;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
SCHEMA' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP SCHEMA'
objectid=25250 schemaname='<NULL>' objectname='test6'
NOTICE: drop cascades to table test6.test
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP SCHEMA'
objectid=<NULL> schemaname='<NULL>' objectname='test6'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP SCHEMA'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP SCHEMA
Command triggers on all DROP commands for TEXT SEARCH
CONFIGURATION/DICTIONARY/PARSER/TEMPLATE show the schema name as the
relation name:
thom@test=# DROP TEXT SEARCH PARSER testnew.test_parser2;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP TEXT
SEARCH PARSER' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP TEXT SEARCH
PARSER' objectid=25265 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP TEXT SEARCH
PARSER' objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP TEXT
SEARCH PARSER' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP TEXT SEARCH PARSER
Still no command triggers firing for CREATE TABLE AS:
thom@test=# CREATE TABLE ctas_test AS SELECT 1::int id, ''::text test;
CREATE TABLE AS
Or for SELECT * INTO... :
thom@test=# SELECT * INTO another_test FROM ctas_test;
SELECT INTO
Regards
--
Thom
Attachments:
command_trigger_test_setup.txt (text/plain, 17.6K) download
CREATE OR REPLACE FUNCTION public.cmd_trg_info(tg_when text, cmd_tag text, objectid oid, schemaname text, objectname text)
RETURNS void
LANGUAGE plpgsql
AS $function$
BEGIN
RAISE NOTICE E'Command trigger: tg_when=\'%\' cmd_tag=\'%\' objectid=% schemaname=\'%\' objectname=\'%\'', tg_when, cmd_tag, objectid, schemaname, objectname;
END; $function$;
CREATE OR REPLACE FUNCTION public.cmd_trg_info_any(tg_when text, cmd_tag text, objectid oid, schemaname text, objectname text)
RETURNS void
LANGUAGE plpgsql
AS $function$
BEGIN
RAISE NOTICE E'Command trigger on any: tg_when=\'%\' cmd_tag=\'%\' objectid=% schemaname=\'%\' objectname=\'%\'', tg_when, cmd_tag, objectid, schemaname, objectname;
END; $function$;
-- before command triggers
CREATE COMMAND TRIGGER cmd_trg_before_any_command BEFORE ANY COMMAND EXECUTE PROCEDURE cmd_trg_info_any();
CREATE COMMAND TRIGGER cmd_trg_before_alter_aggregate BEFORE ALTER AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_collation BEFORE ALTER COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_domain BEFORE ALTER DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_extension BEFORE ALTER EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_foreign_data_wrapper BEFORE ALTER FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_foreign_table BEFORE ALTER FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_function BEFORE ALTER FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_language BEFORE ALTER LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_operator BEFORE ALTER OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_operator_class BEFORE ALTER OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_operator_family BEFORE ALTER OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_schema BEFORE ALTER SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_server BEFORE ALTER SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_table BEFORE ALTER TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_text_search_configuration BEFORE ALTER TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_text_search_dictionary BEFORE ALTER TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_text_search_parser BEFORE ALTER TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_text_search_template BEFORE ALTER TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_trigger BEFORE ALTER TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_type BEFORE ALTER TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_alter_user_mapping BEFORE ALTER USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_aggregate BEFORE CREATE AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_cast BEFORE CREATE CAST EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_collation BEFORE CREATE COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_conversion BEFORE CREATE CONVERSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_domain BEFORE CREATE DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_extension BEFORE CREATE EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_foreign_data_wrapper BEFORE CREATE FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_foreign_table BEFORE CREATE FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_function BEFORE CREATE FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_index BEFORE CREATE INDEX EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_language BEFORE CREATE LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_operator BEFORE CREATE OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_operator_class BEFORE CREATE OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_operator_family BEFORE CREATE OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_rule BEFORE CREATE RULE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_schema BEFORE CREATE SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_sequence BEFORE CREATE SEQUENCE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_server BEFORE CREATE SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_table BEFORE CREATE TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_text_search_configuration BEFORE CREATE TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_text_search_dictionary BEFORE CREATE TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_text_search_parser BEFORE CREATE TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_text_search_template BEFORE CREATE TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_trigger BEFORE CREATE TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_type BEFORE CREATE TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_user_mapping BEFORE CREATE USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_create_view BEFORE CREATE VIEW EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_aggregate BEFORE DROP AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_cast BEFORE DROP CAST EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_collation BEFORE DROP COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_conversion BEFORE DROP CONVERSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_domain BEFORE DROP DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_extension BEFORE DROP EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_foreign_data_wrapper BEFORE DROP FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_foreign_table BEFORE DROP FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_function BEFORE DROP FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_index BEFORE DROP INDEX EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_language BEFORE DROP LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_operator BEFORE DROP OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_operator_class BEFORE DROP OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_operator_family BEFORE DROP OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_rule BEFORE DROP RULE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_schema BEFORE DROP SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_sequence BEFORE DROP SEQUENCE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_server BEFORE DROP SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_table BEFORE DROP TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_text_search_configuration BEFORE DROP TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_text_search_dictionary BEFORE DROP TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_text_search_parser BEFORE DROP TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_text_search_template BEFORE DROP TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_trigger BEFORE DROP TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_type BEFORE DROP TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_user_mapping BEFORE DROP USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_before_drop_view BEFORE DROP VIEW EXECUTE PROCEDURE cmd_trg_info();
-- after command triggers
CREATE COMMAND TRIGGER cmd_trg_after_any_command AFTER ANY COMMAND EXECUTE PROCEDURE cmd_trg_info_any();
CREATE COMMAND TRIGGER cmd_trg_after_alter_aggregate AFTER ALTER AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_collation AFTER ALTER COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_domain AFTER ALTER DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_extension AFTER ALTER EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_foreign_data_wrapper AFTER ALTER FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_foreign_table AFTER ALTER FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_function AFTER ALTER FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_language AFTER ALTER LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_operator AFTER ALTER OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_operator_class AFTER ALTER OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_operator_family AFTER ALTER OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_schema AFTER ALTER SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_server AFTER ALTER SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_table AFTER ALTER TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_text_search_configuration AFTER ALTER TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_text_search_dictionary AFTER ALTER TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_text_search_parser AFTER ALTER TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_text_search_template AFTER ALTER TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_trigger AFTER ALTER TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_type AFTER ALTER TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_alter_user_mapping AFTER ALTER USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_aggregate AFTER CREATE AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_cast AFTER CREATE CAST EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_collation AFTER CREATE COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_conversion AFTER CREATE CONVERSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_domain AFTER CREATE DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_extension AFTER CREATE EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_foreign_data_wrapper AFTER CREATE FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_foreign_table AFTER CREATE FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_function AFTER CREATE FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_index AFTER CREATE INDEX EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_language AFTER CREATE LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_operator AFTER CREATE OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_operator_class AFTER CREATE OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_operator_family AFTER CREATE OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_rule AFTER CREATE RULE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_schema AFTER CREATE SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_sequence AFTER CREATE SEQUENCE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_server AFTER CREATE SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_table AFTER CREATE TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_text_search_configuration AFTER CREATE TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_text_search_dictionary AFTER CREATE TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_text_search_parser AFTER CREATE TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_text_search_template AFTER CREATE TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_trigger AFTER CREATE TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_type AFTER CREATE TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_user_mapping AFTER CREATE USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_create_view AFTER CREATE VIEW EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_aggregate AFTER DROP AGGREGATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_cast AFTER DROP CAST EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_collation AFTER DROP COLLATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_conversion AFTER DROP CONVERSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_domain AFTER DROP DOMAIN EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_extension AFTER DROP EXTENSION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_foreign_data_wrapper AFTER DROP FOREIGN DATA WRAPPER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_foreign_table AFTER DROP FOREIGN TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_function AFTER DROP FUNCTION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_index AFTER DROP INDEX EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_language AFTER DROP LANGUAGE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_operator AFTER DROP OPERATOR EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_operator_class AFTER DROP OPERATOR CLASS EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_operator_family AFTER DROP OPERATOR FAMILY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_rule AFTER DROP RULE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_schema AFTER DROP SCHEMA EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_sequence AFTER DROP SEQUENCE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_server AFTER DROP SERVER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_table AFTER DROP TABLE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_text_search_configuration AFTER DROP TEXT SEARCH CONFIGURATION EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_text_search_dictionary AFTER DROP TEXT SEARCH DICTIONARY EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_text_search_parser AFTER DROP TEXT SEARCH PARSER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_text_search_template AFTER DROP TEXT SEARCH TEMPLATE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_trigger AFTER DROP TRIGGER EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_type AFTER DROP TYPE EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_user_mapping AFTER DROP USER MAPPING EXECUTE PROCEDURE cmd_trg_info();
CREATE COMMAND TRIGGER cmd_trg_after_drop_view AFTER DROP VIEW EXECUTE PROCEDURE cmd_trg_info();
command_trigger_regression.sql (text/x-sql, 15.2K) download
-- CREATE TESTS --
CREATE AGGREGATE avgtest(bigint) (
SFUNC=int8_avg_accum,
STYPE=numeric[],
FINALFUNC=numeric_avg,
INITCOND='{0,0}'
);
--Support function
CREATE FUNCTION testcast(text) RETURNS int4 AS $$BEGIN RETURN 4::int4;END;$$ LANGUAGE plpgsql;
CREATE CAST (text AS int4) WITH FUNCTION testcast(text) AS ASSIGNMENT;
CREATE COLLATION "en_GB2"
(LC_COLLATE='en_GB.utf8', LC_CTYPE='en_GB.utf8');
CREATE COLLATION "en_GB3" FROM "en_GB";
CREATE CONVERSION test
FOR 'UTF8'
TO 'SJIS'
FROM utf8_to_sjis;
CREATE DEFAULT CONVERSION test2
FOR 'UTF8'
TO 'SJIS'
FROM utf8_to_sjis;
CREATE DOMAIN us_postal_code AS TEXT
CHECK(
VALUE ~ '^\d{5}$'
OR VALUE ~ '^\d{5}-\d{4}$'
);
CREATE EXTENSION file_fdw;
CREATE EXTENSION IF NOT EXISTS file_fdw;
CREATE FOREIGN DATA WRAPPER file HANDLER file_fdw_handler;
CREATE SERVER file FOREIGN DATA WRAPPER "file_fdw";
CREATE FOREIGN TABLE dict (word text) SERVER "file" OPTIONS ( format 'text', filename '/usr/share/dict/british-english');
CREATE FUNCTION testfunc() RETURNS int AS $$BEGIN RETURN 1;END;$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION testfunc() RETURNS int AS $$BEGIN RETURN 1;END;$$ LANGUAGE plpgsql;
CREATE TABLE test (id int, stuff text);
CREATE INDEX idx_test_1 ON test (id);
CREATE UNIQUE INDEX idx_test_2 ON test (id);
CREATE OPERATOR <<||(
PROCEDURE = int2xor,
LEFTARG = int2,
RIGHTARG = int2,
COMMUTATOR = #);
CREATE OPERATOR CLASS test_op_class
FOR TYPE anyenum USING hash AS
OPERATOR 1 =,
FUNCTION 1 hashenum(anyenum);
CREATE OPERATOR FAMILY test_ops USING btree;
CREATE TABLE test2 (id int, stuff text); -- support for testing rules
CREATE RULE "_RETURN" AS
ON SELECT TO test2
DO INSTEAD
SELECT 234 id, 'test'::text stuff;
CREATE ROLE test; -- support for testing schemas
CREATE SCHEMA test;
CREATE SCHEMA AUTHORIZATION test;
CREATE SCHEMA postgres CREATE TABLE test (id int);
CREATE SEQUENCE test_seq;
CREATE TEMP SEQUENCE test_seq2;
CREATE TEMPORARY SEQUENCE test_seq3;
CREATE TABLE AS SELECT 1::int id, ''::text test;
CREATE TEXT SEARCH CONFIGURATION test (
PARSER = "default"
);
CREATE TEXT SEARCH DICTIONARY test_stem (
TEMPLATE = snowball,
language = 'english', stopwords = 'english'
);
CREATE TEXT SEARCH PARSER test_parser (
START = prsd_start,
GETTOKEN = prsd_nexttoken,
END = prsd_end,
LEXTYPES = prsd_lextype,
HEADLINE = prsd_headline
);
CREATE TEXT SEARCH TEMPLATE test_template (
INIT = dsimple_init,
LEXIZE = dsimple_lexize
);
CREATE OR REPLACE FUNCTION public.dummy_trigger_function() RETURNS trigger AS
$$
BEGIN
RETURN NEW;
END;
$$ LANGUAGE plpgsql; -- support for testing triggers
CREATE TRIGGER trg_test BEFORE INSERT ON test EXECUTE PROCEDURE public.dummy_trigger_function();
CREATE TYPE test.type_test AS
(a integer,
b integer,
c text);
CREATE USER MAPPING FOR postgres SERVER file OPTIONS (user 'test', password 'password');
CREATE VIEW view_test AS SELECT id, stuff FROM public.test;
-- ALTER TESTS --
ALTER AGGREGATE avgtest(bigint) RENAME TO avgtest2;
ALTER AGGREGATE avgtest2(bigint) OWNER TO test;
ALTER AGGREGATE avgtest2(bigint) SET SCHEMA test;
ALTER COLLATION "en_GB2" RENAME TO en_gb_test;
ALTER COLLATION en_gb_test OWNER TO test;
ALTER COLLATION en_gb_test SET SCHEMA test;
ALTER DOMAIN us_postal_code SET DEFAULT 90210;
ALTER DOMAIN us_postal_code DROP DEFAULT;
ALTER DOMAIN us_postal_code SET NOT NULL;
ALTER DOMAIN us_postal_code DROP NOT NULL;
ALTER DOMAIN us_postal_code ADD CONSTRAINT dummy_constraint CHECK (VALUE ~ '^\d{8}$');
ALTER DOMAIN us_postal_code DROP CONSTRAINT dummy_constraint;
ALTER DOMAIN us_postal_code OWNER TO test;
ALTER DOMAIN us_postal_code SET SCHEMA test;
ALTER EXTENSION file_fdw UPDATE TO '1.0';
ALTER EXTENSION file_fdw SET SCHEMA test;
ALTER EXTENSION file_fdw ADD AGGREGATE avgtest2(bigint);
ALTER EXTENSION file_fdw ADD CAST (text AS int4);
ALTER EXTENSION file_fdw ADD COLLATION en_gb_test; -- fails to add
ALTER EXTENSION file_fdw ADD CONVERSION ascii_to_utf8;
ALTER EXTENSION file_fdw ADD DOMAIN test.us_postal_code;
ALTER EXTENSION file_fdw ADD FOREIGN DATA WRAPPER file;
ALTER EXTENSION file_fdw ADD FOREIGN TABLE dict;
ALTER EXTENSION file_fdw ADD FUNCTION testfunc();
ALTER EXTENSION file_fdw ADD OPERATOR <<||(int2,int2);
ALTER EXTENSION file_fdw ADD OPERATOR CLASS test_op_class USING hash;
ALTER EXTENSION file_fdw ADD OPERATOR FAMILY test_ops USING btree;
-- ALTER EXTENSION file_fdw ADD PROCEDURAL LANGUAGE -- Can't test
ALTER EXTENSION file_fdw ADD SCHEMA test;
ALTER EXTENSION file_fdw ADD SEQUENCE test_seq;
ALTER EXTENSION file_fdw ADD SERVER file;
ALTER EXTENSION file_fdw ADD TABLE test;
ALTER EXTENSION file_fdw ADD TEXT SEARCH CONFIGURATION test;
ALTER EXTENSION file_fdw ADD TEXT SEARCH DICTIONARY test_stem;
ALTER EXTENSION file_fdw ADD TEXT SEARCH PARSER test_parser;
ALTER EXTENSION file_fdw ADD TEXT SEARCH TEMPLATE test_template;
ALTER EXTENSION file_fdw ADD TYPE test.type_test;
ALTER EXTENSION file_fdw ADD VIEW view_test;
ALTER EXTENSION file_fdw DROP AGGREGATE avgtest2(bigint);
ALTER EXTENSION file_fdw DROP CAST (text AS int4);
ALTER EXTENSION file_fdw DROP COLLATION en_gb_test; -- fails to add
ALTER EXTENSION file_fdw DROP CONVERSION ascii_to_utf8;
ALTER EXTENSION file_fdw DROP DOMAIN test.us_postal_code;
ALTER EXTENSION file_fdw DROP FOREIGN DATA WRAPPER file;
ALTER EXTENSION file_fdw DROP FOREIGN TABLE dict;
ALTER EXTENSION file_fdw DROP FUNCTION testfunc();
ALTER EXTENSION file_fdw DROP OPERATOR <<||(int2,int2);
ALTER EXTENSION file_fdw DROP OPERATOR CLASS test_op_class USING hash;
ALTER EXTENSION file_fdw DROP OPERATOR FAMILY test_ops USING btree;
-- ALTER EXTENSION file_fdw DROP PROCEDURAL LANGUAGE -- Can't test
ALTER EXTENSION file_fdw DROP SCHEMA test;
ALTER EXTENSION file_fdw DROP SEQUENCE test_seq;
ALTER EXTENSION file_fdw DROP SERVER file;
ALTER EXTENSION file_fdw DROP TABLE test;
ALTER EXTENSION file_fdw DROP TEXT SEARCH CONFIGURATION test;
ALTER EXTENSION file_fdw DROP TEXT SEARCH DICTIONARY test_stem;
ALTER EXTENSION file_fdw DROP TEXT SEARCH PARSER test_parser;
ALTER EXTENSION file_fdw DROP TEXT SEARCH TEMPLATE test_template;
ALTER EXTENSION file_fdw DROP TYPE test.type_test;
ALTER EXTENSION file_fdw DROP VIEW view_test;
CREATE USER supertest SUPERUSER; -- support for alter foreign data wrapper
ALTER FOREIGN DATA WRAPPER file OWNER TO supertest;
ALTER FOREIGN DATA WRAPPER file NO HANDLER:
ALTER FOREIGN DATA WRAPPER file HANDLER test.file_fdw_handler;
ALTER FOREIGN DATA WRAPPER file NO VALIDATOR;
ALTER FOREIGN DATA WRAPPER file VALIDATOR test.file_fdw_validator;
--ALTER FOREIGN DATA WRAPPER file OPTIONS (ADD); -- can't test
--ALTER FOREIGN DATA WRAPPER file OPTIONS (DROP); -- can't test
ALTER FOREIGN TABLE dict RENAME TO dict2;
ALTER FOREIGN TABLE dict2 SET SCHEMA test;
ALTER FOREIGN TABLE test.dict2 OWNER TO test;
ALTER FOREIGN TABLE test.dict2 RENAME COLUMN word TO words;
ALTER FOREIGN TABLE test.dict2 ALTER COLUMN words SET NOT NULL;
ALTER FOREIGN TABLE test.dict2 ALTER COLUMN words DROP NOT NULL;
ALTER FOREIGN TABLE test.dict2 ALTER COLUMN words SET DATA TYPE char(90);
ALTER FOREIGN TABLE test.dict2 DROP COLUMN IF EXISTS test RESTRICT;
ALTER FOREIGN TABLE test.dict2 DROP COLUMN IF EXISTS test CASCADE;
ALTER FOREIGN TABLE test.dict2 ADD COLUMN testcol1 int NULL;
ALTER FOREIGN TABLE test.dict2 ADD COLUMN testcol2 int NOT NULL;
ALTER FOREIGN TABLE test.dict2 DROP COLUMN testcol1;
ALTER FOREIGN TABLE test.dict2 DROP COLUMN testcol2;
--ALTER FOREIGN TABLE test.dict2 OPTIONS (ADD) -- can't test
--ALTER FOREIGN TABLE test.dict2 OPTIONS (DROP) -- can't test
--ALTER FOREIGN TABLE test.dict2 OPTIONS (SET) -- can't test
ALTER FUNCTION testfunc() RENAME TO testfunc2;
ALTER FUNCTION testfunc2() OWNER TO test;
ALTER FUNCTION testfunc2() SET SCHEMA test;
ALTER FUNCTION test.testfunc2() COST 77;
CREATE FUNCTION srf_test() RETURNS SETOF int AS
$$
SELECT x FROM generate_series(1,12) a(x);
$$ LANGUAGE sql; -- support for alter function row change
ALTER FUNCTION srf_test() ROWS 5;
ALTER FUNCTION srf_test() RESET ALL;
ALTER FUNCTION srf_test() SET work_mem TO 1MB;
ALTER FUNCTION srf_test() CALLED ON NULL INPUT;
ALTER FUNCTION srf_test() RETURNS NULL ON NULL INPUT;
ALTER FUNCTION srf_test() STRICT;
ALTER FUNCTION srf_test() IMMUTABLE;
ALTER FUNCTION srf_test() STABLE;
ALTER FUNCTION srf_test() VOLATILE;
ALTER FUNCTION srf_test() EXTERNAL SECURITY INVOKER;
ALTER FUNCTION srf_test() EXTERNAL SECURITY DEFINER;
ALTER LANGUAGE plpgsql RENAME TO plpgsql2;
ALTER LANGUAGE plpgsql2 OWNER TO test;
ALTER OPERATOR <<|| (int2,int2) OWNER TO test;
ALTER OPERATOR <<|| (int2,int2) SET SCHEMA test;
ALTER OPERATOR CLASS test_op_class USING hash RENAME TO test_op_class2;
ALTER OPERATOR CLASS test_op_class2 USING hash OWNER TO test;
ALTER OPERATOR CLASS test_op_class2 USING hash SET SCHEMA test;
ALTER OPERATOR FAMILY test_ops USING btree RENAME TO test_ops2;
ALTER OPERATOR FAMILY test_ops2 USING btree OWNER TO test;
ALTER OPERATOR FAMILY test_ops2 USING btree SET SCHEMA test;
ALTER SCHEMA test RENAME TO testnew;
ALTER SCHEMA testnew OWNER TO test;
ALTER SEQUENCE test_seq OWNER TO test;
ALTER SEQUENCE test_seq RENAME TO test_seq2;
ALTER SEQUENCE test_seq2 SET SCHEMA testnew;
ALTER SEQUENCE testnew.test_seq2 START WITH 3;
ALTER SEQUENCE testnew.test_seq2 RESTART WITH 4;
ALTER SEQUENCE testnew.test_seq2 MINVALUE 3;
ALTER SEQUENCE testnew.test_seq2 NO MINVALUE;
ALTER SEQUENCE testnew.test_seq2 MAXVALUE 900000;
ALTER SEQUENCE testnew.test_seq2 NO MAXVALUE;
ALTER SEQUENCE testnew.test_seq2 CACHE 876;
ALTER SEQUENCE testnew.test_seq2 CYCLE;
ALTER SEQUENCE testnew.test_seq2 NO CYCLE;
CREATE TABLE testnew.seq_table (id int, test text); -- support for testing ALTER SEQUENCE ... OWNED BY ...
ALTER TABLE testnew.seq_table OWNER TO test; -- support for testing ALTER SEQUENCE ... OWNED BY ...
ALTER SEQUENCE testnew.test_seq2 OWNED BY testnew.seq_table.id;
ALTER SERVER file OWNER TO test;
ALTER SERVER file VERSION '1.0';
--ALTER SERVER file OPTIONS (ADD); -- can't test
--ALTER SERVER file OPTIONS (SET); -- can't test
--ALTER SERVER file OPTIONS (DROP); -- can't test
ALTER TABLE test RENAME TO test9;
ALTER TABLE test9 SET SCHEMA testnew;
ALTER TABLE testnew.test9 RENAME COLUMN stuff TO things;
ALTER TABLE testnew.test9 ADD COLUMN alpha text;
ALTER TABLE testnew.test9 DROP COLUMN alpha;
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET DATA TYPE varchar(300);
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET DEFAULT 'test';
ALTER TABLE testnew.test9 ALTER COLUMN alpha DROP DEFAULT;
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET STATISTICS 78;
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET STORAGE PLAIN;
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET NOT NULL;
ALTER TABLE testnew.test9 ALTER COLUMN alpha DROP NOT NULL;
ALTER TABLE testnew.test9 ALTER COLUMN alpha SET (n_distinct = -0.78);
ALTER TABLE testnew.test9 ALTER COLUMN alpha RESET (n_distinct);
ALTER TABLE testnew.test9 ADD CHECK (id > 2) NOT VALID;
ALTER TABLE testnew.test9 ADD CHECK (id < 800000);
ALTER TABLE testnew.test9 SET WITHOUT CLUSTER;
ALTER TABLE testnew.test9 SET WITH OIDS;
ALTER TABLE testnew.test9 SET WITHOUT OIDS;
ALTER TEXT SEARCH CONFIGURATION test RENAME TO test2;
ALTER TEXT SEARCH CONFIGURATION test2 OWNER TO test;
ALTER TEXT SEARCH CONFIGURATION test2 SET SCHEMA testnew;
ALTER TEXT SEARCH CONFIGURATION testnew.test2 ALTER MAPPING REPLACE english_stem WITH dutch_stem;
ALTER TEXT SEARCH DICTIONARY test_stem RENAME TO test_stem2;
ALTER TEXT SEARCH DICTIONARY test_stem2 OWNER TO test;
ALTER TEXT SEARCH DICTIONARY test_stem2 SET SCHEMA testnew;
ALTER TEXT SEARCH DICTIONARY testnew.test_stem2 ( StopWords = dutch );
ALTER TEXT SEARCH PARSER test_parser RENAME TO test_parser2;
ALTER TEXT SEARCH PARSER test_parser2 SET SCHEMA testnew;
ALTER TEXT SEARCH TEMPLATE test_template RENAME TO test_template2;
ALTER TEXT SEARCH TEMPLATE test_template2 SET SCHEMA testnew;
ALTER TRIGGER trg_test ON testnew.test9 RENAME TO trg_test2;
ALTER TYPE testnew.type_test OWNER TO test;
ALTER TYPE testnew.type_test RENAME TO type_test2;
ALTER TYPE testnew.type_test2 SET SCHEMA public;
ALTER TYPE public.type_test2 RENAME ATTRIBUTE a TO z;
ALTER TYPE public.type_test2 ADD ATTRIBUTE alpha text;
ALTER TYPE public.type_test2 ALTER ATTRIBUTE alpha SET DATA TYPE char(90);
ALTER TYPE public.type_test2 DROP ATTRIBUTE alpha;
ALTER VIEW view_test OWNER TO test;
ALTER VIEW view_test RENAME TO view_test2;
ALTER VIEW view_test2 SET SCHEMA testnew;
ALTER VIEW testnew.view_test2 ALTER COLUMN id SET DEFAULT 9;
ALTER VIEW testnew.view_test2 ALTER COLUMN id DROP DEFAULT;
-- DROP TESTS --
DROP AGGREGATE avgtest2(bigint);
DROP AGGREGATE IF EXISTS avgtest2(bigint);
DROP CAST (text AS int4);
DROP CAST IF EXISTS (text AS int4);
DROP COLLATION testnew.en_gb_test;
DROP COLLATION IF EXISTS testnew.en_gb_test;
DROP CONVERSION IF EXISTS big5_to_euc_tw;
DROP DOMAIN testnew.us_postal_code;
DROP DOMAIN IF EXISTS testnew.us_postal_code;
--DROP EXTENSION file_fdw CASCADE; -- save dropping until later as other things are dependant on it
DROP FOREIGN DATA WRAPPER file;
DROP FOREIGN DATA WRAPPER IF EXISTS file;
DROP FOREIGN TABLE test.dict2;
DROP FOREIGN TABLE IF EXISTS test.dict2;
DROP FUNCTION testnew.testfunc();
DROP FUNCTION IF EXISTS testnew.testfunc();
DROP INDEX testnew.idx_test_1;
DROP INDEX IF EXISTS testnew.idx_test_1;
--DROP LANGUAGE -- can't test
DROP OPERATOR <<|| (int2, int2);
DROP OPERATOR IF EXISTS <<|| (int2, int2);
DROP OPERATOR CLASS test_op_class2 USING hash;
DROP OPERATOR CLASS IF EXISTS test_op_class2 USING hash;
DROP OPERATOR FAMILY testnew.test_ops2 USING btree;
DROP OPERATOR FAMILY IF EXISTS testnew.test_ops2 USING btree;
CREATE ROLE role_test; -- support for testing DROP OWNED BY
CREATE TABLE role_test_table (id int, test text);
ALTER TABLE role_test_table OWNER TO role_test;
DROP OWNED BY role_test;
DROP ROLE role_test;
DROP ROLE IF EXISTS role_test;
CREATE RULE notify_test AS ON UPDATE TO seq_table DO ALSO NOTIFY test; -- support for testing DROP RULE
DROP RULE notify_test ON seq_table;
DROP RULE IF EXISTS notify_test ON seq_table;
CREATE SCHEMA test5; -- support for testing DROP SCHEMA
DROP SCHEMA test5;
DROP SCHEMA IF EXISTS test5;
CREATE SCHEMA test6; -- support for testing DROP SCHEMA ... CASCADE
CREATE TABLE test6.test (id int, test text);
DROP SCHEMA test6 CASCADE;
DROP SEQUENCE testnew.test_seq2;
DROP SEQUENCE IF EXISTS testnew.test_seq2;
DROP SERVER file;
DROP SERVER IF EXISTS file;
CREATE TABLE test (id int, test text); -- support for testing DROP TABLE
DROP TABLE test;
DROP TABLE IF EXISTS test;
DROP TEXT SEARCH CONFIGURATION testnew.test2;
DROP TEXT SEARCH CONFIGURATION IF EXISTS testnew.test2;
DROP TEXT SEARCH DICTIONARY testnew.test_stem2;
DROP TEXT SEARCH DICTIONARY IF EXISTS testnew.test_stem2;
DROP TEXT SEARCH PARSER testnew.test_parser2;
DROP TEXT SEARCH PARSER IF EXISTS testnew.test_parser2;
DROP TEXT SEARCH TEMPLATE testnew.test_template2;
DROP TEXT SEARCH TEMPLATE IF EXISTS testnew.test_template2;
CREATE TABLE test (id int, test text); -- support for testing DROP TRIGGER
CREATE TRIGGER trg_test BEFORE INSERT ON test EXECUTE PROCEDURE public.dummy_trigger_function(); -- support for testing DROP TRIGGER
DROP TRIGGER trg_test ON test;
DROP TRIGGER IF EXISTS trg_test ON test;
DROP TYPE public.type_test2;
DROP TYPE IF EXISTS public.type_test2;
-- DROP USER MAPPING -- can't test
DROP VIEW testnew.view_test2;
DROP VIEW IF EXISTS testnew.view_test2;
DROP EXTENSION file_fdw CASCADE;
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-05 20:42 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:10 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 2 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-05 20:42 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Hi,
Thanks for the extensive testing. I'm adding your tests to the
regression suite, and keep wondering if you saw that lots of them were
already covered? Did you try make installcheck?
Thom Brown <thom@linux.com> writes:
> Creating a command trigger using ANY COMMAND results in oid,
> schemaname, objectname (function parameters 4 & 5) not being set for
> either BEFORE or AFTER.
Yes, that's documented. It could be better documented though, it seems.
> There is no support for ALTER CONVERSION.
It was missing in the grammar and docs only, added.
> WARNING: CREATE INDEX CONCURRENTLY is not supported
> DETAIL: The command trigger will not get fired.
>
> This should probably say that it’s not supported on AFTER command
> triggers yet rather than the general DDL itself.
Edited.
> Command triggers for AFTER creating rules don’t return OIDs.
Fixed.
> Command triggers for creating sequences don’t show the schema:
Documented already, it's uneasy to get at it in the code and I figured I
might as well drop the ball on that in the current patch's form.
> Command triggers for AFTER creating extensions with IF NOT EXISTS
> don’t fire, but do in the ANY COMMAND instance:
Fixed.
> Command triggers on CREATE TEXT SEARCH DICTIONARY show the name as garbage:
Fixed, test case added.
> Command triggers for BEFORE CREATE TYPE (exluding ANY COMMAND) don’t
> fire if the type isn’t created due to an error:
Per design, although we might want to talk about it. I made it so that
specific command triggers are only fired after errors checks have been
made.
That's not the case with ANY command triggers so that you can actually
block DDLs on your instances, as has been asked on list.
> The ANY COMMAND trigger fires on creating roles, but there’s no
> corresponding allowance to create the trigger explicitly for creating
> roles.
Roles are global objects, you don't want the behavior of role commands
to depend on which database you happen to have been logged in when
issuing the command. That would call for removing the ANY command
support for them too, but I can't seem to decide about that.
Any input?
> Command triggers for AFTER CREATE VIEW don’t show the schema:
Couldn't reproduce, added test cases.
> Command triggers for BEFORE and AFTER ALTER DOMAIN show a garbage name
> and no schema when dropping a constraint:
Fixed, added test cases.
> Continuing with this same trigger, we do get a schema but a garbage
> name for OWNER TO:
Fixed, added test cases.
> When an ALTER EXTENSION fails to upgrade, the AFTER ANY COMMAND
> trigger fires, but not command triggers specifically for ALTER
> EXTENSION:
>
> Same on ALTER EXTENSION, when failing to add a member, the BEFORE ANY
> COMMAND trigger fires, but not the one specifically for ALTER
> EXTENSION:
Again, per design. Let's talk about it, it will probably need at least
documentation.
> Specific command triggers against ALTER FOREIGN TABLE (i.e. not ANY
> COMMAND) for BEFORE and AFTER aren’t working when renaming columns:
>
> Specific command triggers agains ALTER FUNCTION (i.e. not ANY COMMAND)
> don’t fire for any changes except renaming, changing owner or changing
> schema. Everything else fails to trigger (cost, rows, setting
> configuration parameters, setting strict, security invoker etc.).:
I kept some TODO items as I feared I would get bored tomorrow otherwise…
> There doesn’t appear to be command trigger support for ALTER LARGE OBJECT.
Do we want to have some? Those are in between data and command.
> Specific command triggers on ALTER SEQUENCE don’t fire:
> Specific command triggers on ALTER TABLE don’t fire for renaming columns:
> Also renaming attributes doesn’t fire specific triggers:
> Specific command triggers on ALTER VIEW don’t fire for any type of change:
Kept on the TODO.
> Command triggers on ALTER TYPE when changing owner produce a garbage name:
Fixed along with the DOMAIN test case (same code).
> Specific command triggers on DROP AGGREGATE don’t fire in the IF
> EXISTS scenario if the target object doesn’t exist:
So, do we want to run the command triggers here? Is the IF EXISTS check
to be considered like the other error conditions?
> When adding objects to an extension, then dropping the extension with
> a cascade, the objects are dropped with it, but triggers aren’t fired
> to the removal of those dependant objects:
Yes, that's expected and needs documenting.
> Using DROP OWNED BY allows objects to be dropped without their
> respective specific triggers firing.
Expected too.
> Using DROP SCHEMA … CASACDE also allows objects to be dropped without
> their respective specific triggers firing:
Again, same expectation here.
> Command triggers on all DROP commands for TEXT SEARCH
> CONFIGURATION/DICTIONARY/PARSER/TEMPLATE show the schema name as the
> relation name:
Now that's strange and will keep me awake longer tomorrow.
> Still no command triggers firing for CREATE TABLE AS:
Yes, Andres made CTAS a utility command, he didn't add the code that
make them fire command triggers. I would expect his patch to get in
first, so I don't expect him to be adding that support, I think I will
have to add it when rebasing once his patch has landed.
I'm not sending a revised patch, please use the github branch if you
want to do some more tests already, or ask me for either a new patch
version or a patch-on-patch, as you see fit.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-05 21:10 ` Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-05 21:10 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; Thom Brown <thom@linux.com>; Tom Lane <tgl@sss.pgh.pa.us>
On Monday, March 05, 2012 09:42:00 PM Dimitri Fontaine wrote:
> > Still no command triggers firing for CREATE TABLE AS:
> Yes, Andres made CTAS a utility command, he didn't add the code that
> make them fire command triggers. I would expect his patch to get in
> first, so I don't expect him to be adding that support, I think I will
> have to add it when rebasing once his patch has landed.
That was my assumption as well.
Any opinions about adding the patch to the commitfest other than from dim? I
feel a bit bad adding it to the in-progress one even if its belongs there
because is a part of the command trigger stuff...
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-05 21:33 ` Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-05 21:33 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 5 March 2012 20:42, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Thanks for the extensive testing. I'm adding your tests to the
> regression suite, and keep wondering if you saw that lots of them were
> already covered? Did you try make installcheck?
Yes, but I felt it better that I come up with my own separate tests.
> Thom Brown <thom@linux.com> writes:
>> Creating a command trigger using ANY COMMAND results in oid,
>> schemaname, objectname (function parameters 4 & 5) not being set for
>> either BEFORE or AFTER.
>
> Yes, that's documented. It could be better documented though, it seems.
Is there a reason why we can't provide the OID for ANY COMMAND... if
it's available? I'm guessing it would end up involving having to
special case for every command. :/
>> Command triggers for creating sequences don’t show the schema:
>
> Documented already, it's uneasy to get at it in the code and I figured I
> might as well drop the ball on that in the current patch's form.
Fair enough.
>> Command triggers for BEFORE CREATE TYPE (exluding ANY COMMAND) don’t
>> fire if the type isn’t created due to an error:
>
> Per design, although we might want to talk about it. I made it so that
> specific command triggers are only fired after errors checks have been
> made.
>
> That's not the case with ANY command triggers so that you can actually
> block DDLs on your instances, as has been asked on list.
I don't have any strong feelings about it, so I'll bear it in mind for
future tests.
>> The ANY COMMAND trigger fires on creating roles, but there’s no
>> corresponding allowance to create the trigger explicitly for creating
>> roles.
>
> Roles are global objects, you don't want the behavior of role commands
> to depend on which database you happen to have been logged in when
> issuing the command. That would call for removing the ANY command
> support for them too, but I can't seem to decide about that.
>
> Any input?
If that's your reasoning, then it would make sense to remove ANY
command support for it too.
>> There doesn’t appear to be command trigger support for ALTER LARGE OBJECT.
>
> Do we want to have some? Those are in between data and command.
*shrug* But ANY COMMAND triggers fire for it. So I'd say either
remove support for that, or add a specific trigger.
>> Specific command triggers on DROP AGGREGATE don’t fire in the IF
>> EXISTS scenario if the target object doesn’t exist:
>
> So, do we want to run the command triggers here? Is the IF EXISTS check
> to be considered like the other error conditions?
Maybe. If that's expected behaviour, I'll start expecting it then.
>> When adding objects to an extension, then dropping the extension with
>> a cascade, the objects are dropped with it, but triggers aren’t fired
>> to the removal of those dependant objects:
>
> Yes, that's expected and needs documenting.
>
>> Using DROP OWNED BY allows objects to be dropped without their
>> respective specific triggers firing.
>
> Expected too.
>
>> Using DROP SCHEMA … CASACDE also allows objects to be dropped without
>> their respective specific triggers firing:
>
> Again, same expectation here.
If these are all expected, does it in any way compromise the
effectiveness of DDL triggers in major use-cases?
> I'm not sending a revised patch, please use the github branch if you
> want to do some more tests already, or ask me for either a new patch
> version or a patch-on-patch, as you see fit.
Hmm... how does that work with regards to the commitfest process?
But I'll re-test when you let me know when you've committed your
remaining fixes to Github.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-06 21:04 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-06 21:04 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Hi,
I believed I fixed all known glitches (all were minor quibbles here and
there because of me trying to work too fast), all I know about remaining
in the TODO list is passing the arguments the classic trigger way, I'm
waiting on a "go" from Tom on the way to do it, but well, will try on my
own if that's how busy he is (I just had enough on my plate to be able
to wait for an ack from him).
Thom Brown <thom@linux.com> writes:
>> already covered? Did you try make installcheck?
> Yes, but I felt it better that I come up with my own separate tests.
Ok, great then :)
> Specific command triggers agains ALTER FUNCTION (i.e. not ANY COMMAND)
> don’t fire for any changes except renaming, changing owner or changing
> schema. Everything else fails to trigger (cost, rows, setting
> configuration parameters, setting strict, security invoker etc.).:
> Specific command triggers on ALTER SEQUENCE don’t fire:
> Specific command triggers on ALTER TABLE don’t fire for renaming columns:
> Also renaming attributes doesn’t fire specific triggers:
> Specific command triggers on ALTER VIEW don’t fire for any type of change:
All previous cases and those are now fixed.
> Is there a reason why we can't provide the OID for ANY COMMAND... if
> it's available? I'm guessing it would end up involving having to
> special case for every command. :/
It's not available where it's implemented, to get the OID you need a
full integration into each code path and the idea being the ANY command
trigger is still to be able to catch more DDL than we are supporting for
specific commands.
>> Roles are global objects, you don't want the behavior of role commands
>> to depend on which database you happen to have been logged in when
>> issuing the command. That would call for removing the ANY command
>> support for them too, but I can't seem to decide about that.
>
> If that's your reasoning, then it would make sense to remove ANY
> command support for it too.
I did that in the attached, version 14 of the patch.
>>> There doesn’t appear to be command trigger support for ALTER LARGE OBJECT.
>
> *shrug* But ANY COMMAND triggers fire for it. So I'd say either
> remove support for that, or add a specific trigger.
I tried adding that, but it's implemented in catalog/ and my tries at
having the catalog include file include the commands/cmdtrigger.h file
have been failing. I don't know how to implement that, dismissed for
now.
>> [CASCADE will not run the command triggers for cascaded objects]
> If these are all expected, does it in any way compromise the
> effectiveness of DDL triggers in major use-cases?
I don't think so. When replicating the replica will certainly drop the
same set of dependent objects, for example. Auditing is another story.
Do we want to try having cascaded object support in drop commands?
As the current code is not going through standard_ProcessUtility() in
such cases, I don't think it's possible to do for 9.2.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
command-trigger.v14.patch.gz (application/octet-stream, 65.0K) download
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-06 21:18 ` Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-06 21:18 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 6 March 2012 21:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>> [CASCADE will not run the command triggers for cascaded objects]
>> If these are all expected, does it in any way compromise the
>> effectiveness of DDL triggers in major use-cases?
>
> I don't think so. When replicating the replica will certainly drop the
> same set of dependent objects, for example. Auditing is another story.
> Do we want to try having cascaded object support in drop commands?
I wasn't sure if auditing was one of the rationale behind the feature
or not. If it is, it presents a major problem. How does the replica
know that the objects were dropped?
Thanks for the updated patch and the quick turnaround time. I'll give
it another review.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-06 23:25 ` Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-08 22:24 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-06 23:25 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 6 March 2012 21:18, Thom Brown <thom@linux.com> wrote:
> On 6 March 2012 21:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>> [CASCADE will not run the command triggers for cascaded objects]
>>> If these are all expected, does it in any way compromise the
>>> effectiveness of DDL triggers in major use-cases?
>>
>> I don't think so. When replicating the replica will certainly drop the
>> same set of dependent objects, for example. Auditing is another story.
>> Do we want to try having cascaded object support in drop commands?
>
> I wasn't sure if auditing was one of the rationale behind the feature
> or not. If it is, it presents a major problem. How does the replica
> know that the objects were dropped?
>
> Thanks for the updated patch and the quick turnaround time. I'll give
> it another review.
Okay, here's the update:
The message returned by creating a command trigger after create index
is still problematic:
thom@test=# CREATE COMMAND TRIGGER cmd_trg_after_create_index AFTER
CREATE INDEX EXECUTE PROCEDURE cmd_trg_info();
WARNING: AFTER CREATE INDEX CONCURRENTLY triggers are not supported
DETAIL: The command trigger will not get fired.
CREATE COMMAND TRIGGER
The detail suggests that even though the command trigger has been
requested, it won't be fired. Might I suggest:
WARNING: AFTER CREATE INDEX CONCURRENTLY triggers are not supported
DETAIL: The command trigger will not fire on concurrently-created indexes.
CREATE VIEW doesn't return schema:
thom@test=# CREATE VIEW view_test AS SELECT id, stuff FROM public.test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
VIEW' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='view_test'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE VIEW'
objectid=16606 schemaname='<NULL>' objectname='view_test'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
CREATE VIEW
No specific triggers fire when altering a conversion:
thom@test=# ALTER CONVERSION test9 RENAME TO test8;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
CONVERSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
CONVERSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER CONVERSION
Note: I hadn’t previously tested this, but I don’t think it was listed
as supported until now.
No specific triggers fire when altering the properties of a function:
thom@test=# ALTER FUNCTION test.testfunc2() COST 77;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER FUNCTION
No specific triggers fire when altering a sequence:
thom@test=# ALTER SEQUENCE test_seq2 OWNER TO test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER SEQUENCE
thom@test=# ALTER SEQUENCE test_seq2 RESTART WITH 4;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER SEQUENCE
No specific triggers when altering a view:
thom@test=# ALTER VIEW view_test2 SET SCHEMA testnew;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER VIEW
thom@test=# ALTER VIEW testnew.view_test2 ALTER COLUMN id SET DEFAULT 9;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
ALTER VIEW
The object name shown in specific triggers when dropping aggregates
shows the schema name:
thom@test=# DROP AGGREGATE testnew.avgtest2(bigint);
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP AGGREGATE'
objectid=16539 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP AGGREGATE'
objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP AGGREGATE
Same for collations:
thom@test=# DROP COLLATION testnew.en_gb_test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
COLLATION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP COLLATION'
objectid=16542 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP COLLATION'
objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
COLLATION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP COLLATION
When dropping domains, the name of the domain includes the schema name:
thom@test=# DROP DOMAIN testnew.us_postal_code;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP DOMAIN'
objectid=16546 schemaname='testnew'
objectname='testnew.us_postal_code'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP DOMAIN'
objectid=<NULL> schemaname='testnew'
objectname='testnew.us_postal_code'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP DOMAIN'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP DOMAIN
Dropping functions shows the object name as the schema name:
thom@test=# DROP FUNCTION testnew.testfunc2();
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP FUNCTION'
objectid=16557 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP FUNCTION'
objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP FUNCTION
Same with dropping operators:
thom@test=# DROP OPERATOR testnew.<<|| (int2, int2);
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
OPERATOR' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP OPERATOR'
objectid=16566 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP OPERATOR'
objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
OPERATOR' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
DROP OPERATOR
...and operator family:
thom@test=# DROP OPERATOR FAMILY testnew.test_ops2 USING btree;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
OPERATOR FAMILY' objectid=<NULL> schemaname='<NULL>'
objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP OPERATOR
FAMILY' objectid=16571 schemaname='testnew' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP OPERATOR
FAMILY' objectid=<NULL> schemaname='testnew' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
OPERATOR FAMILY' objectid=<NULL> schemaname='<NULL>'
objectname='<NULL>'
DROP OPERATOR FAMILY
… and the same for dropping text search
configuration/dictionary/parser/template.
I hadn't previously tested triggers against CLUSTER, REINDEX, VACUUM
and LOAD, but have tested them now.
When creating a trigger on REINDEX, I get the following message:
thom@test=# CREATE COMMAND TRIGGER cmd_trg_before_reindex BEFORE
REINDEX EXECUTE PROCEDURE cmd_trg_info();
WARNING: REINDEX DATABASE is not supported
DETAIL: The command trigger will not get fired.
My problem with this is the same as what I reported previously for
CREATE INDEX, in that it suggests the DDL itself isn't supported.
But more importantly:
Creating AFTER CLUSTER command triggers produce an error (as expected
since it's not supported), but AFTER REINDEX only produces a warning.
These should be the same, probably both an error.
VACUUM doesn't fire a specific command trigger:
thom@test=# VACUUM;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='VACUUM'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
VACUUM
REINDEX on a table seems to show no schema name but an object name for
specific triggers:
thom@test=# REINDEX TABLE testnew.test9;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='REINDEX'
objectid=16558 schemaname='<NULL>' objectname='testnew'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='REINDEX'
objectid=16558 schemaname='<NULL>' objectname='testnew'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
REINDEX
When REINDEXing an index rather than a table, the table's details are
shown in the trigger. Is this expected?:
thom@test=# REINDEX INDEX testnew.idx_test_2 ;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='REINDEX'
objectid=16565 schemaname='testnew' objectname='test9'
NOTICE: Command trigger: tg_when='AFTER' cmd_tag='REINDEX'
objectid=16565 schemaname='testnew' objectname='test9'
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
REINDEX
REINDEXing the whole database doesn't fire specific command triggers:
thom@test=# REINDEX DATABASE test;
NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
NOTICE: table "pg_catalog.pg_class" was reindexed
<snip>
NOTICE: table "information_schema.sql_features" was reindexed
NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
REINDEX
The same happens for the REINDEX SYSTEM syntax.
Documentation:
I previously noted text which needed correcting that doesn’t seem to
have fixed yet. The email I reported those in misleadingly began with
“Right, hopefully this should be my last piece of list spam...”. The
only one which I feel no longer needs fixing is the first thing I
reported due to the fact that command triggers can now only been
applied against one command at a time. Also disregard the comments in
that email for ALTER and DROP.
You appear to have added support for ALTER CAST, but there isn’t any such DDL.
OPERATOR CLASS and OPERATOR FAMILY are listed twice.
“Note that objects dropped by effect of DROP CASCADE will not provoque
firing a command trigger”
should probably be:
“Note that objects dropped by the effect of DROP CASCADE will not
result in a command trigger firing.”
“That also applis to other dependencies following, as in DROP OWNED BY.”
should be:
“That also applies to other dependencies following, as in DROP OWNED BY.”
Another typo (which was in the email I referred to earlier) is
s/exercize/exercise/.
“Triggers on ANY command support more commands than just this list,
and will only provide the command tag argument as NOT NULL.”
should be:
“Triggers on ANY command support more commands than just this list,
and will provide NULL values for every argument except for the
argument that determines whether the trigger was before or after the
command event, and the command tag.”
This will no doubt need changing to refer to the new trigger variables
if you introduce them.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-07 21:53 ` Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-07 21:53 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 6 March 2012 23:25, Thom Brown <thom@linux.com> wrote:
> On 6 March 2012 21:18, Thom Brown <thom@linux.com> wrote:
>> On 6 March 2012 21:04, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>> [CASCADE will not run the command triggers for cascaded objects]
>>>> If these are all expected, does it in any way compromise the
>>>> effectiveness of DDL triggers in major use-cases?
>>>
>>> I don't think so. When replicating the replica will certainly drop the
>>> same set of dependent objects, for example. Auditing is another story.
>>> Do we want to try having cascaded object support in drop commands?
>>
>> I wasn't sure if auditing was one of the rationale behind the feature
>> or not. If it is, it presents a major problem. How does the replica
>> know that the objects were dropped?
>>
>> Thanks for the updated patch and the quick turnaround time. I'll give
>> it another review.
>
> Okay, here's the update:
>
> The message returned by creating a command trigger after create index
> is still problematic:
>
> thom@test=# CREATE COMMAND TRIGGER cmd_trg_after_create_index AFTER
> CREATE INDEX EXECUTE PROCEDURE cmd_trg_info();
> WARNING: AFTER CREATE INDEX CONCURRENTLY triggers are not supported
> DETAIL: The command trigger will not get fired.
> CREATE COMMAND TRIGGER
>
> The detail suggests that even though the command trigger has been
> requested, it won't be fired. Might I suggest:
>
> WARNING: AFTER CREATE INDEX CONCURRENTLY triggers are not supported
> DETAIL: The command trigger will not fire on concurrently-created indexes.
>
>
>
> CREATE VIEW doesn't return schema:
>
> thom@test=# CREATE VIEW view_test AS SELECT id, stuff FROM public.test;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='CREATE
> VIEW' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='CREATE VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='view_test'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='CREATE VIEW'
> objectid=16606 schemaname='<NULL>' objectname='view_test'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='CREATE VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> CREATE VIEW
>
> No specific triggers fire when altering a conversion:
>
> thom@test=# ALTER CONVERSION test9 RENAME TO test8;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
> CONVERSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
> CONVERSION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER CONVERSION
>
> Note: I hadn’t previously tested this, but I don’t think it was listed
> as supported until now.
>
>
> No specific triggers fire when altering the properties of a function:
>
> thom@test=# ALTER FUNCTION test.testfunc2() COST 77;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
> FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
> FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER FUNCTION
>
>
> No specific triggers fire when altering a sequence:
>
> thom@test=# ALTER SEQUENCE test_seq2 OWNER TO test;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
> SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
> SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER SEQUENCE
>
> thom@test=# ALTER SEQUENCE test_seq2 RESTART WITH 4;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER
> SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER
> SEQUENCE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER SEQUENCE
>
>
> No specific triggers when altering a view:
>
> thom@test=# ALTER VIEW view_test2 SET SCHEMA testnew;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER VIEW
>
> thom@test=# ALTER VIEW testnew.view_test2 ALTER COLUMN id SET DEFAULT 9;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER VIEW'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> ALTER VIEW
>
>
> The object name shown in specific triggers when dropping aggregates
> shows the schema name:
>
> thom@test=# DROP AGGREGATE testnew.avgtest2(bigint);
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP AGGREGATE'
> objectid=16539 schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP AGGREGATE'
> objectid=<NULL> schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
> AGGREGATE' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> DROP AGGREGATE
>
> Same for collations:
>
> thom@test=# DROP COLLATION testnew.en_gb_test;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> COLLATION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP COLLATION'
> objectid=16542 schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP COLLATION'
> objectid=<NULL> schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
> COLLATION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> DROP COLLATION
>
>
> When dropping domains, the name of the domain includes the schema name:
>
> thom@test=# DROP DOMAIN testnew.us_postal_code;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> DOMAIN' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP DOMAIN'
> objectid=16546 schemaname='testnew'
> objectname='testnew.us_postal_code'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP DOMAIN'
> objectid=<NULL> schemaname='testnew'
> objectname='testnew.us_postal_code'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP DOMAIN'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> DROP DOMAIN
>
>
> Dropping functions shows the object name as the schema name:
>
> thom@test=# DROP FUNCTION testnew.testfunc2();
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP FUNCTION'
> objectid=16557 schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP FUNCTION'
> objectid=<NULL> schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
> FUNCTION' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> DROP FUNCTION
>
>
> Same with dropping operators:
>
> thom@test=# DROP OPERATOR testnew.<<|| (int2, int2);
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> OPERATOR' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP OPERATOR'
> objectid=16566 schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP OPERATOR'
> objectid=<NULL> schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
> OPERATOR' objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> DROP OPERATOR
>
>
> ...and operator family:
>
> thom@test=# DROP OPERATOR FAMILY testnew.test_ops2 USING btree;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='DROP
> OPERATOR FAMILY' objectid=<NULL> schemaname='<NULL>'
> objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='DROP OPERATOR
> FAMILY' objectid=16571 schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='DROP OPERATOR
> FAMILY' objectid=<NULL> schemaname='testnew' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='DROP
> OPERATOR FAMILY' objectid=<NULL> schemaname='<NULL>'
> objectname='<NULL>'
> DROP OPERATOR FAMILY
>
>
> … and the same for dropping text search
> configuration/dictionary/parser/template.
>
>
> I hadn't previously tested triggers against CLUSTER, REINDEX, VACUUM
> and LOAD, but have tested them now.
>
> When creating a trigger on REINDEX, I get the following message:
>
> thom@test=# CREATE COMMAND TRIGGER cmd_trg_before_reindex BEFORE
> REINDEX EXECUTE PROCEDURE cmd_trg_info();
> WARNING: REINDEX DATABASE is not supported
> DETAIL: The command trigger will not get fired.
>
> My problem with this is the same as what I reported previously for
> CREATE INDEX, in that it suggests the DDL itself isn't supported.
>
> But more importantly:
>
> Creating AFTER CLUSTER command triggers produce an error (as expected
> since it's not supported), but AFTER REINDEX only produces a warning.
> These should be the same, probably both an error.
>
>
> VACUUM doesn't fire a specific command trigger:
>
> thom@test=# VACUUM;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='VACUUM'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> VACUUM
>
>
> REINDEX on a table seems to show no schema name but an object name for
> specific triggers:
>
> thom@test=# REINDEX TABLE testnew.test9;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='REINDEX'
> objectid=16558 schemaname='<NULL>' objectname='testnew'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='REINDEX'
> objectid=16558 schemaname='<NULL>' objectname='testnew'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> REINDEX
>
>
> When REINDEXing an index rather than a table, the table's details are
> shown in the trigger. Is this expected?:
>
> thom@test=# REINDEX INDEX testnew.idx_test_2 ;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='REINDEX'
> objectid=16565 schemaname='testnew' objectname='test9'
> NOTICE: Command trigger: tg_when='AFTER' cmd_tag='REINDEX'
> objectid=16565 schemaname='testnew' objectname='test9'
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> REINDEX
>
>
> REINDEXing the whole database doesn't fire specific command triggers:
>
> thom@test=# REINDEX DATABASE test;
> NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> NOTICE: table "pg_catalog.pg_class" was reindexed
> <snip>
> NOTICE: table "information_schema.sql_features" was reindexed
> NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='REINDEX'
> objectid=<NULL> schemaname='<NULL>' objectname='<NULL>'
> REINDEX
>
> The same happens for the REINDEX SYSTEM syntax.
>
>
> Documentation:
>
> I previously noted text which needed correcting that doesn’t seem to
> have fixed yet. The email I reported those in misleadingly began with
> “Right, hopefully this should be my last piece of list spam...”. The
> only one which I feel no longer needs fixing is the first thing I
> reported due to the fact that command triggers can now only been
> applied against one command at a time. Also disregard the comments in
> that email for ALTER and DROP.
>
> You appear to have added support for ALTER CAST, but there isn’t any such DDL.
>
> OPERATOR CLASS and OPERATOR FAMILY are listed twice.
>
> “Note that objects dropped by effect of DROP CASCADE will not provoque
> firing a command trigger”
> should probably be:
> “Note that objects dropped by the effect of DROP CASCADE will not
> result in a command trigger firing.”
>
> “That also applis to other dependencies following, as in DROP OWNED BY.”
> should be:
> “That also applies to other dependencies following, as in DROP OWNED BY.”
>
> Another typo (which was in the email I referred to earlier) is
> s/exercize/exercise/.
>
> “Triggers on ANY command support more commands than just this list,
> and will only provide the command tag argument as NOT NULL.”
> should be:
> “Triggers on ANY command support more commands than just this list,
> and will provide NULL values for every argument except for the
> argument that determines whether the trigger was before or after the
> command event, and the command tag.”
>
> This will no doubt need changing to refer to the new trigger variables
> if you introduce them.
I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
think any trigger should fire on a read-only standby.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-09 14:09 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-09 14:09 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <thom@linux.com> wrote:
> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
> think any trigger should fire on a read-only standby.
Why ever not?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 14:22 ` Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-09 14:22 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 9 March 2012 14:09, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <thom@linux.com> wrote:
>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>> think any trigger should fire on a read-only standby.
>
> Why ever not?
Sorry, I meant any command trigger. It's because none of the commands
can be run on a standby, so the triggers don't seem appropriate.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-09 14:30 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 15:05 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-09 17:29 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 3 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-09 14:30 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
> On 9 March 2012 14:09, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <thom@linux.com> wrote:
>>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>>> think any trigger should fire on a read-only standby.
>>
>> Why ever not?
>
> Sorry, I meant any command trigger. It's because none of the commands
> can be run on a standby, so the triggers don't seem appropriate.
I'm not convinced. Right now, it's fairly useless - all the triggers
could possibly do is throw an error, and an error is going to get
thrown anyway, so it's only a question of which error message the user
will see. But we discussed before the idea of adding a capability for
BEFORE triggers to request that the actual execution of the command
get skipped, and then it's possible to imagine this being useful.
Someone could even use a command trigger that detects which machine
it's running on, and if it's the standby, uses dblink to execute the
command on the master, or something crazy like that. Command triggers
could also be useful for logging all attempts to execute a particular
command, which is probably still appropriate on the standby.
I think that it will be a good thing to try to treat Hot Standby mode
as much like regular operation as is reasonably possible, across the
board.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 14:35 ` Thom Brown <thom@linux.com>
2012-03-09 14:47 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-09 14:35 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 9 March 2012 14:30, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>> On 9 March 2012 14:09, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <thom@linux.com> wrote:
>>>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>>>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>>>> think any trigger should fire on a read-only standby.
>>>
>>> Why ever not?
>>
>> Sorry, I meant any command trigger. It's because none of the commands
>> can be run on a standby, so the triggers don't seem appropriate.
>
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capability for
> BEFORE triggers to request that the actual execution of the command
> get skipped, and then it's possible to imagine this being useful.
> Someone could even use a command trigger that detects which machine
> it's running on, and if it's the standby, uses dblink to execute the
> command on the master, or something crazy like that. Command triggers
> could also be useful for logging all attempts to execute a particular
> command, which is probably still appropriate on the standby.
>
> I think that it will be a good thing to try to treat Hot Standby mode
> as much like regular operation as is reasonably possible, across the
> board.
I see your point. My suggestion to Dimitri in another email was
either enable triggers for all commands or none. At the moment it's
only available on utility commands.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-09 14:47 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 15:02 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 17:51 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-09 14:47 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown <thom@linux.com> wrote:
> I see your point. My suggestion to Dimitri in another email was
> either enable triggers for all commands or none. At the moment it's
> only available on utility commands.
Yeah, that's clearly not the best of all possible worlds. :-)
I think we had better look seriously at postponing this patch to 9.3.
Your reviewing is obviously moving things forward rapidly, but I think
it's unrealistic to think this is going to be in a committable state
any time in the next week or two.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:47 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 15:02 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-09 15:02 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 9 March 2012 14:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 9:35 AM, Thom Brown <thom@linux.com> wrote:
>> I see your point. My suggestion to Dimitri in another email was
>> either enable triggers for all commands or none. At the moment it's
>> only available on utility commands.
>
> Yeah, that's clearly not the best of all possible worlds. :-)
>
> I think we had better look seriously at postponing this patch to 9.3.
> Your reviewing is obviously moving things forward rapidly, but I think
> it's unrealistic to think this is going to be in a committable state
> any time in the next week or two.
That's unfortunate if that's the case. I'll dedicate any bandwidth
necessary for additional testing as I would really like to see this
get in, but if it transpires there's more outstanding work and
polishing needed than time Dimitri personally has available, then I
guess it'll have to be a 9.3 feature. :'(
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:47 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 17:51 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 19:16 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-09 17:51 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Robert Haas <robertmhaas@gmail.com> writes:
> I think we had better look seriously at postponing this patch to 9.3.
I understand why you're drawing that conclusion, but I don't think
that's the best we can do here, by a long shot.
> Your reviewing is obviously moving things forward rapidly, but I think
> it's unrealistic to think this is going to be in a committable state
> any time in the next week or two.
What's happening is that I've been abusing Thom's availability, leaving
him with the testing and fixing oddities along the way. Those came
mainly from an attempt at being as automatic as possible when writing
commands support. I'm now about done reviewing each and every call site
and having them covered in the tests.
What remains to be done now is how to pass down arguments to the
triggers (switching from function arguments to trigger style magic
variables, per Tom request), and review REINDEX and CREATE OPERATOR
CLASS support. That's about it.
The API and the call sites location have been stable for a long time
now, and are following your previous round of review. The catalog
storage and commands grammar are ok too, we've been hashing them out.
We've been very careful about not introducing code path hazards, the
only novelty being a new place to ERROR out (no fancy silent utility
command execution control).
Really, I would think we're about there now. I would be rather surprised
not to be able to finish that patch by the end of next week, and will
arrange myself to be able to devote more time on it each day if that's
what needed.
Remember that we intend to build an extension providing a C-coded
function doing the heavy lifting of back parsing the command string from
the Node parse tree, with the goal of having Slony, Londiste and Bucardo
able to use that and implement support for DLLs. I really want that to
happen in 2012.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:47 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 17:51 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-09 19:16 ` Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-09 19:16 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Thom Brown <thom@linux.com>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On Fri, Mar 9, 2012 at 12:51 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I think we had better look seriously at postponing this patch to 9.3.
>
> I understand why you're drawing that conclusion, but I don't think
> that's the best we can do here, by a long shot.
Well, if you get to the point where you're done churning the code in
the next week or so, I'm willing to do one or two more rounds of
serious review, but if that doesn't get us there then I think we need
to give up. The energy you've put into this is commendable, but we're
about to start the third month of this CommitFest, and until we get
this release at least to beta or so, we can't start any new
CommitFests or branch the tree. That basically means that nothing
else of mine is going to get committed until the current crop of
patches are dealt with - or for a good while after, for that matter,
but getting the current crop of patches dealt with is the first step.
Of course, I also want to have a good release and I understand the
necessity of spending time on other people's patches as well as my
own, as I believe I've demonstrated, but I don't want to stay in that
mode indefinitely, which I think is an understandable position.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 15:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-09 15:09 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 15:29 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2 siblings, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-09 15:05 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>> Sorry, I meant any command trigger. It's because none of the commands
>> can be run on a standby, so the triggers don't seem appropriate.
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capability for
> BEFORE triggers to request that the actual execution of the command
> get skipped, and then it's possible to imagine this being useful.
Um, surely the "you can't do that in a read-only session" error is going
to get thrown long before the command trigger could be called?
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 15:05 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-09 15:09 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-09 15:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
On 9 March 2012 15:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Right now, it's fairly useless - all the triggers
>> could possibly do is throw an error, and an error is going to get
>> thrown anyway, so it's only a question of which error message the user
>> will see. But we discussed before the idea of adding a capability for
>> BEFORE triggers to request that the actual execution of the command
>> get skipped, and then it's possible to imagine this being useful.
>
> Um, surely the "you can't do that in a read-only session" error is going
> to get thrown long before the command trigger could be called?
Yes, at the moment that's the case. I said that this wasn't the case
for utility commands but I've noticed the message is different for
those:
ERROR: cannot execute VACUUM during recovery
vs
ERROR: cannot execute CREATE TABLE in a read-only transaction
So my complaint around that was misleading and wrong.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 15:05 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-09 15:29 ` Robert Haas <robertmhaas@gmail.com>
1 sibling, 0 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-09 15:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
On Fri, Mar 9, 2012 at 10:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>>> Sorry, I meant any command trigger. It's because none of the commands
>>> can be run on a standby, so the triggers don't seem appropriate.
>
>> I'm not convinced. Right now, it's fairly useless - all the triggers
>> could possibly do is throw an error, and an error is going to get
>> thrown anyway, so it's only a question of which error message the user
>> will see. But we discussed before the idea of adding a capability for
>> BEFORE triggers to request that the actual execution of the command
>> get skipped, and then it's possible to imagine this being useful.
>
> Um, surely the "you can't do that in a read-only session" error is going
> to get thrown long before the command trigger could be called?
Hmmm.... yeah.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-09 17:29 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2 siblings, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-09 17:29 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Robert Haas <robertmhaas@gmail.com> writes:
> I'm not convinced. Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see. But we discussed before the idea of adding a capability for
> BEFORE triggers to request that the actual execution of the command
> get skipped, and then it's possible to imagine this being useful.
> Someone could even use a command trigger that detects which machine
> it's running on, and if it's the standby, uses dblink to execute the
> command on the master, or something crazy like that. Command triggers
> could also be useful for logging all attempts to execute a particular
> command, which is probably still appropriate on the standby.
There are some other use cases, like using plsh to go apt-get install an
extension's package when you see the master just created it, so that
your read only queries on the hot standby have a chance of loading the
code you need.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-08 22:24 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 00:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-08 22:24 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Hi,
Thom Brown <thom@linux.com> writes:
> The message returned by creating a command trigger after create index
> is still problematic:
Fixed. I'm attaching an incremental patch here, the github branch is
updated too.
> CREATE VIEW doesn't return schema:
Fixed, and as an added bonus I fixed the CREATE SEQUENCE oddity about
that too.
> No specific triggers fire when altering a conversion:
Couldn't reproduce, works here, added tests.
> No specific triggers fire when altering the properties of a function:
Fixed.
> No specific triggers fire when altering a sequence:
Couldn't reproduce, added tests.
> No specific triggers when altering a view:
Same again.
> The object name shown in specific triggers when dropping aggregates
> shows the schema name:
> Same for collations:
> Dropping functions shows the object name as the schema name:
> Same with dropping operators:
> ...and operator family:
> … and the same for dropping text search
> configuration/dictionary/parser/template.
Fixed in the attached (all of those where located at exactly the same
place, by the way, that's one fix).
> When dropping domains, the name of the domain includes the schema name:
I'm using format_type_be(objectId) so that int4 is integer and int8
bigint etc, but that's adding the schemaname. I didn't have time to look
for another API that wouldn't add the schemaname nor to add one myself,
will do that soon.
> I hadn't previously tested triggers against CLUSTER, REINDEX, VACUUM
> and LOAD, but have tested them now.
Cool :)
> When creating a trigger on REINDEX, I get the following message:
Fixed.
> Creating AFTER CLUSTER command triggers produce an error (as expected
> since it's not supported), but AFTER REINDEX only produces a warning.
> These should be the same, probably both an error.
Fixed.
> VACUUM doesn't fire a specific command trigger:
I though it was better this way, I changed my mind and completed the code.
> REINDEX on a table seems to show no schema name but an object name for
> specific triggers:
Still on the TODO.
> When REINDEXing an index rather than a table, the table's details are
> shown in the trigger. Is this expected?:
Yeah well. Will see about how much damage needs to be done in the
current APIs, running out of steam for tonight's batch.
> REINDEXing the whole database doesn't fire specific command triggers:
We don't want to because REINDEX DATABASE is managing transactions on
its own, same limitation as with AFTER VACUUM and all. Will have a look
at what it takes to document that properly.
> Documentation:
Fixed.
Thom Brown <thom@linux.com> writes:
> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
> think any trigger should fire on a read-only standby.
Well I'm not sold on that myself (think pl/untrusted that would reach
out to the OS and do whatever is needed there). You can even set the
session_replication_role GUC to replica and only have the replica
command triggers fired.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
more-cmd-trigger-fixes.patch (text/x-patch, 33.1K) download
*** a/doc/src/sgml/ref/create_command_trigger.sgml
--- b/doc/src/sgml/ref/create_command_trigger.sgml
***************
*** 41,48 **** CREATE COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFOR
ALTER LANGUAGE
ALTER OPERATOR
ALTER OPERATOR CLASS
- ALTER OPERATOR CLASS
- ALTER OPERATOR FAMILY
ALTER OPERATOR FAMILY
ALTER SCHEMA
ALTER SEQUENCE
--- 41,46 ----
***************
*** 137,146 **** CREATE COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFOR
</para>
<para>
! Note that objects dropped by effect of <literal>DROP CASCADE</literal>
! will not provoque firing a command trigger, only the top-level command
! for the main object will fire a command trigger. That also applis to
! other dependencies following, as in <literal>DROP OWNED BY</literal>.
</para>
<para>
--- 135,145 ----
</para>
<para>
! Note that objects dropped by the effect of <literal>DROP
! CASCADE</literal> will not result in a command trigger firing, only the
! top-level command for the main object will fire a command trigger. That
! also applies to other dependencies following, as in <literal>DROP OWNED
! BY</literal>.
</para>
<para>
***************
*** 192,198 **** CREATE COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFOR
you are connected to.
</para>
<para>
! Commands that exercize their own transaction control are only
supported in <literal>BEFORE</literal> command triggers, that's the
case for <literal>VACUUM</literal>, <literal>CLUSTER</literal>
<literal>CREATE INDEX CONCURRENTLY</literal>, and <literal>REINDEX
--- 191,197 ----
you are connected to.
</para>
<para>
! Commands that exercise their own transaction control are only
supported in <literal>BEFORE</literal> command triggers, that's the
case for <literal>VACUUM</literal>, <literal>CLUSTER</literal>
<literal>CREATE INDEX CONCURRENTLY</literal>, and <literal>REINDEX
***************
*** 215,220 **** CREATE COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFOR
--- 214,224 ----
not to be able to take over control from a superuser.
</para>
<para>
+ Triggers on ANY command support more commands than just this list, and
+ will provide NULL values for every argument except for the argument
+ that determines whether the trigger was before or after the command
+ event, and the command tag.
+
Triggers on <literal>ANY</literal> command support more commands than
just this list, and will only provide the <literal>command
tag</literal> argument as <literal>NOT NULL</literal>. Supporting more
***************
*** 244,257 **** CREATE COMMAND TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFOR
tag</literal>, <literal>objectid</literal> (can be null in case of a
BEFORE CREATE or an AFTER DROP command trigger
timing), <literal>schemaname</literal> (can be null for objects not
! living in a schema, and for sequences due to an implementation limit)
! and <literal>object name</literal> (can be null for any command
! triggers).
! </para>
! <para>
! The command <literal>CREATE SEQUENCE</literal> lacks support for
! the <literal>schemaname</literal> command trigger argument, it
! provides <literal>NULL</literal> in all cases.
</para>
</listitem>
</varlistentry>
--- 248,255 ----
tag</literal>, <literal>objectid</literal> (can be null in case of a
BEFORE CREATE or an AFTER DROP command trigger
timing), <literal>schemaname</literal> (can be null for objects not
! living in a schema) and <literal>object name</literal> (can be null
! for any command triggers).
</para>
</listitem>
</varlistentry>
*** a/src/backend/commands/cmdtrigger.c
--- b/src/backend/commands/cmdtrigger.c
***************
*** 185,197 **** CreateCmdTrigger(CreateCmdTrigStmt *stmt, const char *queryString)
ereport(WARNING,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("AFTER CREATE INDEX CONCURRENTLY triggers are not supported"),
! errdetail("The command trigger will not get fired.")));
if (strcmp(stmt->command, "REINDEX") == 0)
ereport(WARNING,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("REINDEX DATABASE is not supported"),
! errdetail("The command trigger will not get fired.")));
if (funcrettype != VOIDOID)
ereport(ERROR,
--- 185,197 ----
ereport(WARNING,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("AFTER CREATE INDEX CONCURRENTLY triggers are not supported"),
! errdetail("The command trigger will not fire on concurrently-created indexes.")));
if (strcmp(stmt->command, "REINDEX") == 0)
ereport(WARNING,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("REINDEX DATABASE is not supported"),
! errdetail("The command trigger will not fire on REINDEX DATABASE.")));
if (funcrettype != VOIDOID)
ereport(ERROR,
*** a/src/backend/commands/dropcmds.c
--- b/src/backend/commands/dropcmds.c
***************
*** 316,323 **** get_object_name(CommandContext cmd, ObjectType objtype,
case OBJECT_FOREIGN_SERVER:
case OBJECT_OPCLASS:
case OBJECT_OPFAMILY:
! cmd->objectname = strVal(linitial(objname));
break;
default:
elog(ERROR, "unexpected object type (%d)", (int)objtype);
break;
--- 316,331 ----
case OBJECT_FOREIGN_SERVER:
case OBJECT_OPCLASS:
case OBJECT_OPFAMILY:
! {
! int len = list_length(objname);
! if (len == 1)
! cmd->objectname = strVal(linitial(objname));
! else if (len == 2)
! cmd->objectname = strVal(lsecond(objname));
! else
! elog(ERROR, "unexpected name list length (%d)", len);
break;
+ }
default:
elog(ERROR, "unexpected object type (%d)", (int)objtype);
break;
*** a/src/backend/commands/functioncmds.c
--- b/src/backend/commands/functioncmds.c
***************
*** 1324,1329 **** AlterFunction(AlterFunctionStmt *stmt)
--- 1324,1330 ----
List *set_items = NIL;
DefElem *cost_item = NULL;
DefElem *rows_item = NULL;
+ CommandContextData cmd;
rel = heap_open(ProcedureRelationId, RowExclusiveLock);
***************
*** 1433,1444 **** AlterFunction(AlterFunctionStmt *stmt)
--- 1434,1461 ----
repl_val, repl_null, repl_repl);
}
+ /* Call BEFORE ALTER FUNCTION command triggers */
+ InitCommandContext(&cmd, (Node *)stmt, false);
+
+ if (CommandFiresTriggers(&cmd))
+ {
+ cmd.objectId = InvalidOid;
+ cmd.objectname = pstrdup(NameStr(procForm->proname));
+ cmd.schemaname = get_namespace_name(procForm->pronamespace);
+
+ ExecBeforeCommandTriggers(&cmd);
+ }
+
/* Do the update */
simple_heap_update(rel, &tup->t_self, tup);
CatalogUpdateIndexes(rel, tup);
heap_close(rel, NoLock);
heap_freetuple(tup);
+
+ /* Call AFTER ALTER FUNCTION command triggers */
+ if (CommandFiresAfterTriggers(&cmd))
+ ExecAfterCommandTriggers(&cmd);
}
/*
*** a/src/backend/commands/sequence.c
--- b/src/backend/commands/sequence.c
***************
*** 213,233 **** DefineSequence(CreateSeqStmt *seq)
stmt->tablespacename = NULL;
stmt->if_not_exists = false;
! /*
! * Call BEFORE CREATE SEQUENCE triggers
! */
InitCommandContext(&cmd, (Node *)seq, false);
! if (CommandFiresTriggers(&cmd))
! {
! cmd.objectId = InvalidOid;
! cmd.objectname = NameStr(name);
! cmd.schemaname = NULL; /* can't publish it easily enough here */
!
! ExecBeforeCommandTriggers(&cmd);
! }
!
! seqoid = DefineRelation(stmt, RELKIND_SEQUENCE, seq->ownerId);
Assert(seqoid != InvalidOid);
rel = heap_open(seqoid, AccessExclusiveLock);
--- 213,222 ----
stmt->tablespacename = NULL;
stmt->if_not_exists = false;
! /* Prepare BEFORE CREATE SEQUENCE triggers */
InitCommandContext(&cmd, (Node *)seq, false);
! seqoid = DefineRelation(stmt, RELKIND_SEQUENCE, seq->ownerId, &cmd);
Assert(seqoid != InvalidOid);
rel = heap_open(seqoid, AccessExclusiveLock);
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***************
*** 415,421 **** static void RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid,
* ----------------------------------------------------------------
*/
Oid
! DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
{
char relname[NAMEDATALEN];
Oid namespaceId;
--- 415,421 ----
* ----------------------------------------------------------------
*/
Oid
! DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId, CommandContext cmd)
{
char relname[NAMEDATALEN];
Oid namespaceId;
***************
*** 608,613 **** DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
--- 608,623 ----
}
}
+ /* Exec BEFORE CREATE view|sequence|table|type command triggers */
+ if (CommandFiresTriggers(cmd))
+ {
+ cmd->objectId = InvalidOid;
+ cmd->objectname = pstrdup(relname);
+ cmd->schemaname = get_namespace_name(namespaceId);
+
+ ExecBeforeCommandTriggers(cmd);
+ }
+
/*
* Create the relation. Inherited defaults and constraints are passed in
* for immediate handling --- since they don't need parsing, they can be
***************
*** 670,675 **** DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
--- 680,686 ----
*/
relation_close(rel, NoLock);
+ /* AFTER command triggers are fired from well outside this function */
return relationId;
}
*** a/src/backend/commands/typecmds.c
--- b/src/backend/commands/typecmds.c
***************
*** 2110,2130 **** DefineCompositeType(RangeVar *typevar, List *coldeflist,
}
/*
- * Call BEFORE CREATE (composite) TYPE triggers
- */
- if (CommandFiresTriggers(cmd))
- {
- cmd->objectId = InvalidOid;
- cmd->objectname = createStmt->relation->relname;
- cmd->schemaname = get_namespace_name(typeNamespace);
-
- ExecBeforeCommandTriggers(cmd);
- }
-
- /*
* Finally create the relation. This also creates the type.
*/
! relid = DefineRelation(createStmt, RELKIND_COMPOSITE_TYPE, InvalidOid);
Assert(relid != InvalidOid);
/* Call AFTER CREATE (composite) TYPE triggers */
--- 2110,2118 ----
}
/*
* Finally create the relation. This also creates the type.
*/
! relid = DefineRelation(createStmt, RELKIND_COMPOSITE_TYPE, InvalidOid, cmd);
Assert(relid != InvalidOid);
/* Call AFTER CREATE (composite) TYPE triggers */
*** a/src/backend/commands/vacuum.c
--- b/src/backend/commands/vacuum.c
***************
*** 123,130 **** vacuum(VacuumStmt *vacstmt, Oid relid, bool do_toast,
else
in_outer_xact = IsInTransactionChain(isTopLevel);
! /* CAll BEFORE VACUUM command triggers */
! if (!IsAutoVacuumWorkerProcess() && vacstmt->relation != NULL)
{
CommandContextData cmd;
InitCommandContext(&cmd, (Node *)vacstmt, false);
--- 123,130 ----
else
in_outer_xact = IsInTransactionChain(isTopLevel);
! /* Call BEFORE VACUUM command triggers */
! if (!IsAutoVacuumWorkerProcess())
{
CommandContextData cmd;
InitCommandContext(&cmd, (Node *)vacstmt, false);
***************
*** 132,140 **** vacuum(VacuumStmt *vacstmt, Oid relid, bool do_toast,
if (CommandFiresTriggers(&cmd))
{
cmd.objectId = relid;
- cmd.objectname = vacstmt->relation->relname;
- cmd.schemaname = vacstmt->relation->schemaname;
ExecBeforeCommandTriggers(&cmd);
}
}
--- 132,143 ----
if (CommandFiresTriggers(&cmd))
{
cmd.objectId = relid;
+ if (vacstmt->relation != NULL)
+ {
+ cmd.objectname = vacstmt->relation->relname;
+ cmd.schemaname = vacstmt->relation->schemaname;
+ }
ExecBeforeCommandTriggers(&cmd);
}
}
*** a/src/backend/commands/view.c
--- b/src/backend/commands/view.c
***************
*** 169,186 **** DefineVirtualRelation(RangeVar *relation, List *tlist, bool replace,
lockmode = replace ? AccessExclusiveLock : NoLock;
(void) RangeVarGetAndCheckCreationNamespace(relation, lockmode, &viewOid);
- /*
- * Call BEFORE CREATE VIEW triggers
- */
- if (CommandFiresTriggers(cmd))
- {
- cmd->objectId = InvalidOid;
- cmd->objectname = relation->relname;
- cmd->schemaname = relation->schemaname;
-
- ExecBeforeCommandTriggers(cmd);
- }
-
if (OidIsValid(viewOid) && replace)
{
Relation rel;
--- 169,174 ----
***************
*** 208,213 **** DefineVirtualRelation(RangeVar *relation, List *tlist, bool replace,
--- 196,211 ----
*/
Assert(relation->relpersistence == rel->rd_rel->relpersistence);
+ /* Call BEFORE CREATE VIEW triggers */
+ if (CommandFiresTriggers(cmd))
+ {
+ cmd->objectId = viewOid;
+ cmd->objectname = RelationGetRelationName(rel);
+ cmd->schemaname = get_namespace_name(RelationGetNamespace(rel));
+
+ ExecBeforeCommandTriggers(cmd);
+ }
+
/*
* Create a tuple descriptor to compare against the existing view, and
* verify that the old column list is an initial prefix of the new
***************
*** 282,288 **** DefineVirtualRelation(RangeVar *relation, List *tlist, bool replace,
* existing view, so we don't need more code to complain if "replace"
* is false).
*/
! relid = DefineRelation(createStmt, RELKIND_VIEW, InvalidOid);
Assert(relid != InvalidOid);
return relid;
}
--- 280,286 ----
* existing view, so we don't need more code to complain if "replace"
* is false).
*/
! relid = DefineRelation(createStmt, RELKIND_VIEW, InvalidOid, cmd);
Assert(relid != InvalidOid);
return relid;
}
*** a/src/backend/tcop/utility.c
--- b/src/backend/tcop/utility.c
***************
*** 691,706 **** standard_ProcessUtility(Node *parsetree,
*/
InitCommandContext(&cmd, parsetree, false);
- if (CommandFiresTriggers(&cmd))
- {
- cmd.objectId = InvalidOid;
- cmd.objectname = stmt->relation->relname;
- cmd.schemaname = get_namespace_name(
- RangeVarGetCreationNamespace(stmt->relation));
-
- ExecBeforeCommandTriggers(&cmd);
- }
-
/* Run parse analysis ... */
stmts = transformCreateStmt(stmt, queryString);
--- 691,696 ----
***************
*** 717,723 **** standard_ProcessUtility(Node *parsetree,
/* Create the table itself */
relOid = DefineRelation((CreateStmt *) stmt,
RELKIND_RELATION,
! InvalidOid);
/*
* Let AlterTableCreateToastTable decide if this one
--- 707,714 ----
/* Create the table itself */
relOid = DefineRelation((CreateStmt *) stmt,
RELKIND_RELATION,
! InvalidOid,
! &cmd);
/*
* Let AlterTableCreateToastTable decide if this one
***************
*** 741,747 **** standard_ProcessUtility(Node *parsetree,
/* Create the table itself */
relOid = DefineRelation((CreateStmt *) stmt,
RELKIND_FOREIGN_TABLE,
! InvalidOid);
CreateForeignTable((CreateForeignTableStmt *) stmt,
relOid);
}
--- 732,739 ----
/* Create the table itself */
relOid = DefineRelation((CreateStmt *) stmt,
RELKIND_FOREIGN_TABLE,
! InvalidOid,
! &cmd);
CreateForeignTable((CreateForeignTableStmt *) stmt,
relOid);
}
*** a/src/include/commands/tablecmds.h
--- b/src/include/commands/tablecmds.h
***************
*** 21,27 ****
#include "utils/relcache.h"
! extern Oid DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId);
extern void RemoveRelations(DropStmt *drop);
--- 21,28 ----
#include "utils/relcache.h"
! extern Oid DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
! CommandContext cmd);
extern void RemoveRelations(DropStmt *drop);
*** a/src/test/regress/expected/cmdtriggers.out
--- b/src/test/regress/expected/cmdtriggers.out
***************
*** 26,31 **** alter command trigger snitch_before set disable;
--- 26,32 ----
alter command trigger snitch_before set enable;
alter command trigger snitch_after_ rename to snitch_after;
create command trigger snitch_create_table after create table execute procedure snitch();
+ create command trigger snitch_create_seq after create sequence execute procedure snitch();
create command trigger snitch_create_view after create view execute procedure snitch();
create command trigger snitch_alter_table after alter table execute procedure snitch();
create command trigger snitch_alter_seq after alter sequence execute procedure snitch();
***************
*** 54,59 **** create command trigger snitch_alter_domain before alter domain execute procedure
--- 55,70 ----
create command trigger snitch_create_type before create type execute procedure snitch();
create command trigger snitch_alter_type before alter type execute procedure snitch();
create command trigger snitch_before_alter_function before alter function execute procedure snitch();
+ create command trigger snitch_alter_conversion before alter conversion execute procedure snitch();
+ create command trigger snitch_drop_agg before drop aggregate execute procedure snitch();
+ create command trigger snitch_before_drop_tsconf before drop text search configuration execute procedure snitch();
+ create command trigger snitch_before_drop_tsdict before drop text search dictionary execute procedure snitch();
+ create command trigger snitch_before_drop_tsparser before drop text search parser execute procedure snitch();
+ create command trigger snitch_before_drop_tstmpl before drop text search template execute procedure snitch();
+ create command trigger snitch_vacuum before vacuum execute procedure snitch();
+ create command trigger snitch_reindex before reindex execute procedure snitch();
+ WARNING: REINDEX DATABASE is not supported
+ DETAIL: The command trigger will not fire on REINDEX DATABASE.
create schema cmd;
NOTICE: snitch: BEFORE any CREATE SCHEMA
NOTICE: snitch: BEFORE CREATE SCHEMA <NULL> cmd
***************
*** 63,72 **** NOTICE: snitch: BEFORE any CREATE SCHEMA
--- 74,85 ----
NOTICE: snitch: BEFORE CREATE SCHEMA <NULL> cmd2
NOTICE: snitch: AFTER any CREATE SCHEMA
create role regbob;
+ ERROR: role "regbob" already exists
create table cmd.foo(id bigserial primary key);
NOTICE: snitch: BEFORE any CREATE TABLE
NOTICE: CREATE TABLE will create implicit sequence "foo_id_seq" for serial column "foo.id"
NOTICE: snitch: BEFORE any CREATE SEQUENCE
+ NOTICE: snitch: AFTER CREATE SEQUENCE cmd foo_id_seq
NOTICE: snitch: AFTER any CREATE SEQUENCE
NOTICE: snitch: BEFORE any CREATE INDEX
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
***************
*** 166,171 **** NOTICE: snitch: AFTER ALTER TABLE cmd test
--- 179,185 ----
NOTICE: snitch: AFTER any ALTER TABLE
create sequence test_seq_;
NOTICE: snitch: BEFORE any CREATE SEQUENCE
+ NOTICE: snitch: AFTER CREATE SEQUENCE public test_seq_
NOTICE: snitch: AFTER any CREATE SEQUENCE
alter sequence test_seq_ owner to regbob;
NOTICE: snitch: BEFORE any ALTER SEQUENCE
***************
*** 217,223 **** NOTICE: snitch: AFTER ALTER SEQUENCE cmd test_seq
NOTICE: snitch: AFTER any ALTER SEQUENCE
create view view_test as select id, things from cmd.test;
NOTICE: snitch: BEFORE any CREATE VIEW
! NOTICE: snitch: AFTER CREATE VIEW <NULL> view_test
NOTICE: snitch: AFTER any CREATE VIEW
alter view view_test owner to regbob;
NOTICE: snitch: BEFORE any ALTER VIEW
--- 231,237 ----
NOTICE: snitch: AFTER any ALTER SEQUENCE
create view view_test as select id, things from cmd.test;
NOTICE: snitch: BEFORE any CREATE VIEW
! NOTICE: snitch: AFTER CREATE VIEW public view_test
NOTICE: snitch: AFTER any CREATE VIEW
alter view view_test owner to regbob;
NOTICE: snitch: BEFORE any ALTER VIEW
***************
*** 243,250 **** cluster cmd.foo using foo_pkey;
--- 257,270 ----
NOTICE: snitch: BEFORE any CLUSTER
vacuum cmd.foo;
NOTICE: snitch: BEFORE any VACUUM
+ NOTICE: snitch: BEFORE VACUUM cmd foo
vacuum;
NOTICE: snitch: BEFORE any VACUUM
+ NOTICE: snitch: BEFORE VACUUM <NULL> <NULL>
+ reindex table cmd.foo;
+ NOTICE: snitch: BEFORE any REINDEX
+ NOTICE: snitch: BEFORE REINDEX <NULL> cmd
+ NOTICE: snitch: AFTER any REINDEX
set session_replication_role to replica;
create table cmd.bar();
reset session_replication_role;
***************
*** 254,278 **** NOTICE: snitch: AFTER any CREATE INDEX
drop index cmd.idx_foo;
NOTICE: snitch: BEFORE any DROP INDEX
NOTICE: snitch: AFTER any DROP INDEX
! create function cmd.fun(int) returns text language sql
as $$ select t from cmd.foo where id = $1; $$;
NOTICE: snitch: BEFORE any CREATE FUNCTION
! NOTICE: snitch: AFTER CREATE FUNCTION cmd fun
NOTICE: snitch: AFTER any CREATE FUNCTION
! alter function cmd.fun(int) strict;
NOTICE: snitch: BEFORE any ALTER FUNCTION
NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function cmd.fun(int) rename to notfun;
NOTICE: snitch: BEFORE any ALTER FUNCTION
! NOTICE: snitch: BEFORE ALTER FUNCTION cmd fun
NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function cmd.notfun(int) set schema public;
NOTICE: snitch: BEFORE any ALTER FUNCTION
NOTICE: snitch: BEFORE ALTER FUNCTION cmd notfun
! NOTICE: snitch: AFTER ALTER FUNCTION public notfun
NOTICE: snitch: AFTER any ALTER FUNCTION
! drop function public.notfun(int);
NOTICE: snitch: BEFORE any DROP FUNCTION
NOTICE: snitch: AFTER any DROP FUNCTION
create function cmd.plus1(int) returns bigint language sql
--- 274,310 ----
drop index cmd.idx_foo;
NOTICE: snitch: BEFORE any DROP INDEX
NOTICE: snitch: AFTER any DROP INDEX
! create function fun(int) returns text language sql
as $$ select t from cmd.foo where id = $1; $$;
NOTICE: snitch: BEFORE any CREATE FUNCTION
! NOTICE: snitch: AFTER CREATE FUNCTION public fun
NOTICE: snitch: AFTER any CREATE FUNCTION
! alter function fun(int) strict;
NOTICE: snitch: BEFORE any ALTER FUNCTION
+ NOTICE: snitch: BEFORE ALTER FUNCTION public fun
+ NOTICE: snitch: AFTER ALTER FUNCTION public fun
NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function fun(int) rename to notfun;
NOTICE: snitch: BEFORE any ALTER FUNCTION
! NOTICE: snitch: BEFORE ALTER FUNCTION public fun
! NOTICE: snitch: AFTER ALTER FUNCTION public notfun
! NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function notfun(int) set schema cmd;
! NOTICE: snitch: BEFORE any ALTER FUNCTION
! NOTICE: snitch: BEFORE ALTER FUNCTION public notfun
NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function cmd.notfun(int) owner to regbob;
NOTICE: snitch: BEFORE any ALTER FUNCTION
NOTICE: snitch: BEFORE ALTER FUNCTION cmd notfun
! NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
! NOTICE: snitch: AFTER any ALTER FUNCTION
! alter function cmd.notfun(int) cost 77;
! NOTICE: snitch: BEFORE any ALTER FUNCTION
! NOTICE: snitch: BEFORE ALTER FUNCTION cmd notfun
! NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
NOTICE: snitch: AFTER any ALTER FUNCTION
! drop function cmd.notfun(int);
NOTICE: snitch: BEFORE any DROP FUNCTION
NOTICE: snitch: AFTER any DROP FUNCTION
create function cmd.plus1(int) returns bigint language sql
***************
*** 306,311 **** NOTICE: snitch: BEFORE any ALTER AGGREGATE
--- 338,344 ----
NOTICE: snitch: AFTER any ALTER AGGREGATE
drop aggregate public.avg(float8);
NOTICE: snitch: BEFORE any DROP AGGREGATE
+ NOTICE: snitch: BEFORE DROP AGGREGATE public avg
NOTICE: snitch: AFTER any DROP AGGREGATE
create collation cmd.french (LOCALE = 'fr_FR');
NOTICE: snitch: BEFORE any CREATE COLLATION
***************
*** 423,430 **** NOTICE: snitch: BEFORE ALTER TRIGGER cmd footg
NOTICE: snitch: AFTER any ALTER TRIGGER
drop trigger foo_trigger on cmd.foo;
NOTICE: snitch: BEFORE any DROP TRIGGER
! NOTICE: snitch: BEFORE DROP TRIGGER <NULL> cmd
! NOTICE: snitch: AFTER any DROP TRIGGER
create text search configuration test (parser = "default");
NOTICE: snitch: BEFORE any CREATE TEXT SEARCH CONFIGURATION
NOTICE: snitch: AFTER CREATE TEXT SEARCH CONFIGURATION public test
--- 456,478 ----
NOTICE: snitch: AFTER any ALTER TRIGGER
drop trigger foo_trigger on cmd.foo;
NOTICE: snitch: BEFORE any DROP TRIGGER
! ERROR: unexpected name list length (3)
! create conversion test for 'utf8' to 'sjis' from utf8_to_sjis;
! NOTICE: snitch: BEFORE any CREATE CONVERSION
! NOTICE: snitch: AFTER any CREATE CONVERSION
! create default conversion test2 for 'utf8' to 'sjis' from utf8_to_sjis;
! NOTICE: snitch: BEFORE any CREATE CONVERSION
! NOTICE: snitch: AFTER any CREATE CONVERSION
! alter conversion test2 rename to test3;
! NOTICE: snitch: BEFORE any ALTER CONVERSION
! NOTICE: snitch: BEFORE ALTER CONVERSION public test2
! NOTICE: snitch: AFTER any ALTER CONVERSION
! drop conversion test3;
! NOTICE: snitch: BEFORE any DROP CONVERSION
! NOTICE: snitch: AFTER any DROP CONVERSION
! drop conversion test;
! NOTICE: snitch: BEFORE any DROP CONVERSION
! NOTICE: snitch: AFTER any DROP CONVERSION
create text search configuration test (parser = "default");
NOTICE: snitch: BEFORE any CREATE TEXT SEARCH CONFIGURATION
NOTICE: snitch: AFTER CREATE TEXT SEARCH CONFIGURATION public test
***************
*** 453,458 **** create text search template test_template (
--- 501,522 ----
NOTICE: snitch: BEFORE any CREATE TEXT SEARCH TEMPLATE
NOTICE: snitch: AFTER CREATE TEXT SEARCH TEMPLATE public test_template
NOTICE: snitch: AFTER any CREATE TEXT SEARCH TEMPLATE
+ drop text search configuration test;
+ NOTICE: snitch: BEFORE any DROP TEXT SEARCH CONFIGURATION
+ NOTICE: snitch: BEFORE DROP TEXT SEARCH CONFIGURATION public test
+ NOTICE: snitch: AFTER any DROP TEXT SEARCH CONFIGURATION
+ drop text search dictionary test_stem;
+ NOTICE: snitch: BEFORE any DROP TEXT SEARCH DICTIONARY
+ NOTICE: snitch: BEFORE DROP TEXT SEARCH DICTIONARY public test_stem
+ NOTICE: snitch: AFTER any DROP TEXT SEARCH DICTIONARY
+ drop text search parser test_parser;
+ NOTICE: snitch: BEFORE any DROP TEXT SEARCH PARSER
+ NOTICE: snitch: BEFORE DROP TEXT SEARCH PARSER public test_parser
+ NOTICE: snitch: AFTER any DROP TEXT SEARCH PARSER
+ drop text search template test_template;
+ NOTICE: snitch: BEFORE any DROP TEXT SEARCH TEMPLATE
+ NOTICE: snitch: BEFORE DROP TEXT SEARCH TEMPLATE public test_template
+ NOTICE: snitch: AFTER any DROP TEXT SEARCH TEMPLATE
create function cmd.testcast(text) returns int4 language plpgsql as $$begin return 4::int4;end;$$;
NOTICE: snitch: BEFORE any CREATE FUNCTION
NOTICE: snitch: AFTER CREATE FUNCTION cmd testcast
***************
*** 489,498 **** NOTICE: drop cascades to type cmd2.us_postal_code
NOTICE: snitch: AFTER any DROP SCHEMA
drop role regbob;
NOTICE: snitch: BEFORE any DROP ROLE
! NOTICE: snitch: AFTER any DROP ROLE
drop command trigger snitch_before;
drop command trigger snitch_after;
drop command trigger snitch_create_table;
drop command trigger snitch_create_view;
drop command trigger snitch_alter_table;
drop command trigger snitch_alter_seq;
--- 553,564 ----
NOTICE: snitch: AFTER any DROP SCHEMA
drop role regbob;
NOTICE: snitch: BEFORE any DROP ROLE
! ERROR: role "regbob" cannot be dropped because some objects depend on it
! DETAIL: 3 objects in database foo
drop command trigger snitch_before;
drop command trigger snitch_after;
drop command trigger snitch_create_table;
+ drop command trigger snitch_create_seq;
drop command trigger snitch_create_view;
drop command trigger snitch_alter_table;
drop command trigger snitch_alter_seq;
***************
*** 521,523 **** drop command trigger snitch_alter_domain;
--- 587,597 ----
drop command trigger snitch_create_type;
drop command trigger snitch_alter_type;
drop command trigger snitch_before_alter_function;
+ drop command trigger snitch_alter_conversion;
+ drop command trigger snitch_drop_agg;
+ drop command trigger snitch_before_drop_tsconf;
+ drop command trigger snitch_before_drop_tsdict;
+ drop command trigger snitch_before_drop_tsparser;
+ drop command trigger snitch_before_drop_tstmpl;
+ drop command trigger snitch_vacuum;
+ drop command trigger snitch_reindex;
*** a/src/test/regress/sql/cmdtriggers.sql
--- b/src/test/regress/sql/cmdtriggers.sql
***************
*** 30,35 **** alter command trigger snitch_before set enable;
--- 30,36 ----
alter command trigger snitch_after_ rename to snitch_after;
create command trigger snitch_create_table after create table execute procedure snitch();
+ create command trigger snitch_create_seq after create sequence execute procedure snitch();
create command trigger snitch_create_view after create view execute procedure snitch();
create command trigger snitch_alter_table after alter table execute procedure snitch();
create command trigger snitch_alter_seq after alter sequence execute procedure snitch();
***************
*** 59,64 **** create command trigger snitch_alter_domain before alter domain execute procedure
--- 60,75 ----
create command trigger snitch_create_type before create type execute procedure snitch();
create command trigger snitch_alter_type before alter type execute procedure snitch();
create command trigger snitch_before_alter_function before alter function execute procedure snitch();
+ create command trigger snitch_alter_conversion before alter conversion execute procedure snitch();
+ create command trigger snitch_drop_agg before drop aggregate execute procedure snitch();
+
+ create command trigger snitch_before_drop_tsconf before drop text search configuration execute procedure snitch();
+ create command trigger snitch_before_drop_tsdict before drop text search dictionary execute procedure snitch();
+ create command trigger snitch_before_drop_tsparser before drop text search parser execute procedure snitch();
+ create command trigger snitch_before_drop_tstmpl before drop text search template execute procedure snitch();
+
+ create command trigger snitch_vacuum before vacuum execute procedure snitch();
+ create command trigger snitch_reindex before reindex execute procedure snitch();
create schema cmd;
create schema cmd2;
***************
*** 113,118 **** alter view cmd.view_test2 alter column id drop default;
--- 124,130 ----
cluster cmd.foo using foo_pkey;
vacuum cmd.foo;
vacuum;
+ reindex table cmd.foo;
set session_replication_role to replica;
create table cmd.bar();
***************
*** 121,133 **** reset session_replication_role;
create index idx_foo on cmd.foo(t);
drop index cmd.idx_foo;
! create function cmd.fun(int) returns text language sql
as $$ select t from cmd.foo where id = $1; $$;
! alter function cmd.fun(int) strict;
! alter function cmd.fun(int) rename to notfun;
! alter function cmd.notfun(int) set schema public;
! drop function public.notfun(int);
create function cmd.plus1(int) returns bigint language sql
as $$ select $1::bigint + 1; $$;
--- 133,147 ----
create index idx_foo on cmd.foo(t);
drop index cmd.idx_foo;
! create function fun(int) returns text language sql
as $$ select t from cmd.foo where id = $1; $$;
! alter function fun(int) strict;
! alter function fun(int) rename to notfun;
! alter function notfun(int) set schema cmd;
! alter function cmd.notfun(int) owner to regbob;
! alter function cmd.notfun(int) cost 77;
! drop function cmd.notfun(int);
create function cmd.plus1(int) returns bigint language sql
as $$ select $1::bigint + 1; $$;
***************
*** 185,190 **** create trigger footg before update on cmd.foo for each row execute procedure cmd
--- 199,210 ----
alter trigger footg on cmd.foo rename to foo_trigger;
drop trigger foo_trigger on cmd.foo;
+ create conversion test for 'utf8' to 'sjis' from utf8_to_sjis;
+ create default conversion test2 for 'utf8' to 'sjis' from utf8_to_sjis;
+ alter conversion test2 rename to test3;
+ drop conversion test3;
+ drop conversion test;
+
create text search configuration test (parser = "default");
create text search dictionary test_stem (
***************
*** 205,210 **** create text search template test_template (
--- 225,235 ----
lexize = dsimple_lexize
);
+ drop text search configuration test;
+ drop text search dictionary test_stem;
+ drop text search parser test_parser;
+ drop text search template test_template;
+
create function cmd.testcast(text) returns int4 language plpgsql as $$begin return 4::int4;end;$$;
create cast (text as int4) with function cmd.testcast(text) as assignment;
***************
*** 218,223 **** drop command trigger snitch_before;
--- 243,249 ----
drop command trigger snitch_after;
drop command trigger snitch_create_table;
+ drop command trigger snitch_create_seq;
drop command trigger snitch_create_view;
drop command trigger snitch_alter_table;
drop command trigger snitch_alter_seq;
***************
*** 247,249 **** drop command trigger snitch_alter_domain;
--- 273,285 ----
drop command trigger snitch_create_type;
drop command trigger snitch_alter_type;
drop command trigger snitch_before_alter_function;
+ drop command trigger snitch_alter_conversion;
+ drop command trigger snitch_drop_agg;
+
+ drop command trigger snitch_before_drop_tsconf;
+ drop command trigger snitch_before_drop_tsdict;
+ drop command trigger snitch_before_drop_tsparser;
+ drop command trigger snitch_before_drop_tstmpl;
+
+ drop command trigger snitch_vacuum;
+ drop command trigger snitch_reindex;
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-08 22:24 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-09 00:28 ` Thom Brown <thom@linux.com>
2012-03-09 11:53 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 21:38 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-09 00:28 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 8 March 2012 22:24, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
We're getting there. :)
> Hi,
>
> Thom Brown <thom@linux.com> writes:
>> The message returned by creating a command trigger after create index
>> is still problematic:
>
> Fixed. I'm attaching an incremental patch here, the github branch is
> updated too.
Confirmed.
>> CREATE VIEW doesn't return schema:
>
> Fixed, and as an added bonus I fixed the CREATE SEQUENCE oddity about
> that too.
Yes, working now.
>> No specific triggers fire when altering a conversion:
>
> Couldn't reproduce, works here, added tests.
My apologies. It seems I neglected to set up a specific trigger for
it. It does indeed work.
>> No specific triggers fire when altering the properties of a function:
>
> Fixed.
Yes, tried every property available and working in every case now.
>> No specific triggers fire when altering a sequence:
>
> Couldn't reproduce, added tests.
Again, I wrongly assumed I had set up a command trigger for this. I
think it's because I based my specific triggers on what was listed on
the CREATE COMMAND TRIGGER documentation page, and those were only
recently added. This is working fine.
>> No specific triggers when altering a view:
>
> Same again.
Working correctly. (see above)
>> The object name shown in specific triggers when dropping aggregates
>> shows the schema name:
>> Same for collations:
>> Dropping functions shows the object name as the schema name:
>> Same with dropping operators:
>> ...and operator family:
>> … and the same for dropping text search
>> configuration/dictionary/parser/template.
>
> Fixed in the attached (all of those where located at exactly the same
> place, by the way, that's one fix).
CREATE OPERATOR CLASS now shows objectname as 'hash' instead of its
name where it's declared as "USING hash". This isn't a problem with
ALTER/DROP OPERATOR CLASS. Everything else above works as expected
now.
>> When dropping domains, the name of the domain includes the schema name:
>
> I'm using format_type_be(objectId) so that int4 is integer and int8
> bigint etc, but that's adding the schemaname. I didn't have time to look
> for another API that wouldn't add the schemaname nor to add one myself,
> will do that soon.
Okay, skipping test.
>> When creating a trigger on REINDEX, I get the following message:
>
> Fixed.
Could we change this to "REINDEX DATABASE triggers are not supported"?
This way it would be consistent with the "AFTER CREATE INDEX
CONCURRENTLY" warning.
>> VACUUM doesn't fire a specific command trigger:
>
> I though it was better this way, I changed my mind and completed the code.
Yes, working now.
>> REINDEX on a table seems to show no schema name but an object name for
>> specific triggers:
>
> Still on the TODO.
Skipped.
>> When REINDEXing an index rather than a table, the table's details are
>> shown in the trigger. Is this expected?:
>
> Yeah well. Will see about how much damage needs to be done in the
> current APIs, running out of steam for tonight's batch.
Skipped.
>> Documentation:
>
> Fixed.
ALTER CAST is still listed and needs removing, not just from the
documentation but every place it's used your code too. I can
currently create a trigger for it, but it's impossible for it to fire
since there's no such command.
All these corrections I mentioned previously still needs to be made:
“A command trigger's function must return void, the only it can aborts
the execution of the command is by raising an exception.”
should be:
“A command trigger's function must return void. It can then only
abort the execution of the command by raising an exception.”
Remove:
“For a constraint trigger, this is also the name to use when modifying
the trigger's behavior using SET CONSTRAINTS.”
“that's the case for VACUUM, CLUSTER CREATE INDEX CONCURRENTLY, and
REINDEX DATABASE.”
should be:
“that's the case for VACUUM, CLUSTER, CREATE INDEX CONCURRENTLY, and
REINDEX DATABASE.”
> Thom Brown <thom@linux.com> writes:
>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on
>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't
>> think any trigger should fire on a read-only standby.
>
> Well I'm not sold on that myself (think pl/untrusted that would reach
> out to the OS and do whatever is needed there). You can even set the
> session_replication_role GUC to replica and only have the replica
> command triggers fired.
All other command triggers don't fire on read-only standbys, and the
inconsistency doesn't seem right. On the one hand all
CREATE/DROP/ALTER triggers aren't fired because of the "cannot execute
<command> in a read-only transaction" error message, but triggers do
occur before utility commands, which would otherwise display the same
message, and might not display it at all if the trigger causes an
error in its function call. So it seems like they should either all
fire, or none of them should. What are you thoughts?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-08 22:24 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 00:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-09 11:53 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-09 11:53 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 9 March 2012 00:28, Thom Brown <thom@linux.com> wrote:
> On 8 March 2012 22:24, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>
> We're getting there. :)
It was late last night and I forgot to get around to testing pg_dump,
which isn't working correctly:
--
-- Name: cmd_trg_after_alter_aggregate; Type: COMMAND TRIGGER; Schema:
-; Owner:
--
CREATE COMMAND TRIGGER cmd_trg_after_alter_aggregate AFTER"ALTER
AGGREGATE" EXECUTE PROCEDURE cmd_trg_info ();
There shouldn't be quotes around the command, and when removing them,
ensure there's a space before the command. All variations of the
ALTER statements in the dump are fine, so are CREATE statements for
ANY COMMAND command triggers.
Also I notice that CREATE/ALTER/DROP COMMAND TRIGGER appears just
before CREATE/ALTER/DROP TRIGGER in the documentation. This breaks
the alphabetical order and I wasn't expecting to find it there when
scanning down the page. Could we move them into an alphabetic
position?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-08 22:24 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 00:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-09 21:38 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 22:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-09 21:38 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
Hi,
Please find attached v15 of the patch, addressing all known issues apart
from the trigger function argument passing style. Expect a new patch
with that taken care of early next week.
(The github branch too, should you be using that)
Thom Brown <thom@linux.com> writes:
> CREATE OPERATOR CLASS now shows objectname as 'hash' instead of its
> name where it's declared as "USING hash". This isn't a problem with
> ALTER/DROP OPERATOR CLASS. Everything else above works as expected
> now.
Ah yes that needed a special case, it's properly handled now, and
tested.
>>> When dropping domains, the name of the domain includes the schema name:
Fixed.
> Could we change this to "REINDEX DATABASE triggers are not supported"?
> This way it would be consistent with the "AFTER CREATE INDEX
> CONCURRENTLY" warning.
Sure, done.
>>> REINDEX on a table seems to show no schema name but an object name for
>>> specific triggers:
Was a typo, fixed.
>>> When REINDEXing an index rather than a table, the table's details are
>>> shown in the trigger. Is this expected?:
Fixed.
> ALTER CAST is still listed and needs removing, not just from the
> documentation but every place it's used your code too. I can
> currently create a trigger for it, but it's impossible for it to fire
> since there's no such command.
Removed.
> All these corrections I mentioned previously still needs to be made:
That's about the docs, I edited them accordingly to your comments.
>> Thom Brown <thom@linux.com> writes:
> All other command triggers don't fire on read-only standbys, and the
> inconsistency doesn't seem right. On the one hand all
> CREATE/DROP/ALTER triggers aren't fired because of the "cannot execute
> <command> in a read-only transaction" error message, but triggers do
> occur before utility commands, which would otherwise display the same
> message, and might not display it at all if the trigger causes an
> error in its function call. So it seems like they should either all
> fire, or none of them should. What are you thoughts?
The others trigger don't fire because an ERROR case is detected before
they have a chance to run, much like on a primary in some ERROR cases.
Thom Brown <thom@linux.com> writes:
> It was late last night and I forgot to get around to testing pg_dump,
> which isn't working correctly:
Fixed.
> Also I notice that CREATE/ALTER/DROP COMMAND TRIGGER appears just
> before CREATE/ALTER/DROP TRIGGER in the documentation. This breaks
> the alphabetical order and I wasn't expecting to find it there when
> scanning down the page. Could we move them into an alphabetic
> position?
I don't see that problem in the source files, could you be more specific?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
command-trigger.v15.patch.gz (application/octet-stream, 67.4K) download
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-08 22:24 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 00:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-09 21:38 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-09 22:42 ` Thom Brown <thom@linux.com>
0 siblings, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-09 22:42 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>; Tom Lane <tgl@sss.pgh.pa.us>
On 9 March 2012 21:38, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Please find attached v15 of the patch, addressing all known issues apart
> from the trigger function argument passing style. Expect a new patch
> with that taken care of early next week.
>
> (The github branch too, should you be using that)
>
> Thom Brown <thom@linux.com> writes:
>> CREATE OPERATOR CLASS now shows objectname as 'hash' instead of its
>> name where it's declared as "USING hash". This isn't a problem with
>> ALTER/DROP OPERATOR CLASS. Everything else above works as expected
>> now.
>
> Ah yes that needed a special case, it's properly handled now, and
> tested.
Confirmed.
>>>> When dropping domains, the name of the domain includes the schema name:
>
> Fixed.
Confirmed.
>> Could we change this to "REINDEX DATABASE triggers are not supported"?
>> This way it would be consistent with the "AFTER CREATE INDEX
>> CONCURRENTLY" warning.
>
> Sure, done.
Confirmed, thanks.
>>>> REINDEX on a table seems to show no schema name but an object name for
>>>> specific triggers:
>
> Was a typo, fixed.
Confirmed
>>>> When REINDEXing an index rather than a table, the table's details are
>>>> shown in the trigger. Is this expected?:
>
> Fixed.
Confirmed.
>> ALTER CAST is still listed and needs removing, not just from the
>> documentation but every place it's used your code too. I can
>> currently create a trigger for it, but it's impossible for it to fire
>> since there's no such command.
>
> Removed.
Confirmed that it's removed from the code. Just needs removing from
the docs too now. (doc/src/sgml/ref/create_command_trigger.sgml)
>> All these corrections I mentioned previously still needs to be made:
>
> That's about the docs, I edited them accordingly to your comments.
Confirmed.
>>> Thom Brown <thom@linux.com> writes:
>> All other command triggers don't fire on read-only standbys, and the
>> inconsistency doesn't seem right. On the one hand all
>> CREATE/DROP/ALTER triggers aren't fired because of the "cannot execute
>> <command> in a read-only transaction" error message, but triggers do
>> occur before utility commands, which would otherwise display the same
>> message, and might not display it at all if the trigger causes an
>> error in its function call. So it seems like they should either all
>> fire, or none of them should. What are you thoughts?
>
> The others trigger don't fire because an ERROR case is detected before
> they have a chance to run, much like on a primary in some ERROR cases.
Yes, I've since discovered that I shouldn't have been treating them
equally due to the different type of error those sets of commands
generate. That's fine then.
> Thom Brown <thom@linux.com> writes:
>> It was late last night and I forgot to get around to testing pg_dump,
>> which isn't working correctly:
>
> Fixed.
Confirmed.
>> Also I notice that CREATE/ALTER/DROP COMMAND TRIGGER appears just
>> before CREATE/ALTER/DROP TRIGGER in the documentation. This breaks
>> the alphabetical order and I wasn't expecting to find it there when
>> scanning down the page. Could we move them into an alphabetic
>> position?
>
> I don't see that problem in the source files, could you be more specific?
I can't see the problem in the source either, but when viewing
postgresql/doc/src/sgml/html/reference.html in my browser, CREATE
COMMAND TRIGGER appears between CREATE TRIGGER and CREATE TYPE. Not
sure why though.
Unless you're cleverly distracted me away from some issue that's yet
to be resolved, that appears to be nearly all my concerns addressed.
All that appears to remain is the trigger-variable stuff which you
said shall arrive early next week, and also the that odd doc issue I
mentioned in the paragraph above (although that could just be
something weird happening when I build it). Sounds like I have the
weekend off. :)
Thanks Dimitri.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-16 20:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-19 18:51 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-16 20:54 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Andres Freund <andres@anarazel.de> writes:
> [ ctas-01.patch ]
I'm starting to look at this now. For a patch that's supposed to
de-complicate things, it seems pretty messy :-(
One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
That used to work, but now you get
regression=# explain select * into foo from tenk1;
ERROR: INTO is only allowed on first SELECT of UNION/INTERSECT/EXCEPT
LINE 1: explain select * into foo from tenk1;
^
and while fixing the parse analysis for that is probably not too hard,
it would still fail to work nicely, since explain.c lacks support for
CreateTableAsStmt utility statements. I think we'd have to invent
something parallel to ExplainExecuteQuery to support this, and I really
doubt that it's worth the trouble. Does anyone have a problem with
desupporting the case?
Also, it seems to me that the patch is spending way too much effort on
trying to exactly duplicate the old error messages for various flavors
of "INTO not allowed here", and still not succeeding terribly well.
I'm inclined to just have a one-size-fits-all message in
transformSelectStmt, which will fire if intoClause hasn't been cleared
before we get there; any objections?
A couple of other cosmetic thoughts: I'm tempted to split the execution
support out into a new file, rather than bloat tablecmds.c any further;
and I'm wondering if the interface to EXECUTE INTO can't be simplified.
(It may have been a mistake to remove the IntoClause in ExecuteStmt.)
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-16 21:07 ` Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-03-16 21:07 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Friday, March 16, 2012 09:54:47 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > [ ctas-01.patch ]
>
> I'm starting to look at this now.
Great!
> For a patch that's supposed to de-complicate things, it seems pretty messy
:-(
Yea. It started out simple but never stopped getting more complicated. Getting
rid of the duplication still seems to make sense to me though.
> One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
> That used to work, but now you get
>
> regression=# explain select * into foo from tenk1;
> ERROR: INTO is only allowed on first SELECT of UNION/INTERSECT/EXCEPT
> LINE 1: explain select * into foo from tenk1;
> ^
>
> and while fixing the parse analysis for that is probably not too hard,
> it would still fail to work nicely, since explain.c lacks support for
> CreateTableAsStmt utility statements.I think we'd have to invent
> something parallel to ExplainExecuteQuery to support this, and I really
> doubt that it's worth the trouble. Does anyone have a problem with
> desupporting the case?
I am all for removing it.
> Also, it seems to me that the patch is spending way too much effort on
> trying to exactly duplicate the old error messages for various flavors
> of "INTO not allowed here", and still not succeeding terribly well.
> I'm inclined to just have a one-size-fits-all message in
> transformSelectStmt, which will fire if intoClause hasn't been cleared
> before we get there; any objections?
I was/am decidedly unhappy about the whole error message stuff. Thats what
turned the patch from removing lines to making it bigger than before.
I tried to be compatible to make sure I understood what was happening. I am
fine with making it one simple error message.
> A couple of other cosmetic thoughts: I'm tempted to split the execution
> support out into a new file, rather than bloat tablecmds.c any further;
> and I'm wondering if the interface to EXECUTE INTO can't be simplified.
> (It may have been a mistake to remove the IntoClause in ExecuteStmt.)
Hm. I vote against keeping the IntoClause stuff in ExecuteStmt. Splitting
stuff from tablecmd.c seems sensible though.
One more thing I disliked quite a bit was the duplication of the EXECUTE
handling. Do you see a way to deduplicate that?
If you give me some hints about what to change I am happy to revise the patch
myself should you prefer that.
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-16 21:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-16 21:31 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Andres Freund <andres@anarazel.de> writes:
> One more thing I disliked quite a bit was the duplication of the EXECUTE
> handling. Do you see a way to deduplicate that?
Yeah, that's what's bugging me, too. I think a chunk of the problem is
that you're insisting on having control come back to CreateTableAs()
to perform the table creation. I'm thinking that if the table creation
were to be moved into the tuple receiver's startup routine, we could
avoid needing to get control back between ExecutorStartup and
ExecutorRun, and then all that would be required would be to call
ExecuteQuery with a different DestReceiver.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-16 21:37 ` Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-03-16 21:37 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > One more thing I disliked quite a bit was the duplication of the EXECUTE
> > handling. Do you see a way to deduplicate that?
> Yeah, that's what's bugging me, too. I think a chunk of the problem is
> that you're insisting on having control come back to CreateTableAs()
> to perform the table creation. I'm thinking that if the table creation
> were to be moved into the tuple receiver's startup routine, we could
> avoid needing to get control back between ExecutorStartup and
> ExecutorRun, and then all that would be required would be to call
> ExecuteQuery with a different DestReceiver.
Hm. I seriously dislike doing that in the receiver. I can't really point out
why though. Unsurprisingly I like getting the control back to CreateTableAs...
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-16 21:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-16 21:52 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Andres Freund <andres@anarazel.de> writes:
> On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
>> I'm thinking that if the table creation
>> were to be moved into the tuple receiver's startup routine, we could
>> avoid needing to get control back between ExecutorStartup and
>> ExecutorRun, and then all that would be required would be to call
>> ExecuteQuery with a different DestReceiver.
> Hm. I seriously dislike doing that in the receiver. I can't really point out
> why though. Unsurprisingly I like getting the control back to CreateTableAs...
I don't see the argument. Receiver startup functions are intended to do
exactly this type of thing. I'd be okay with leaving it in
CreateTableAs if it didn't contort the code to do so, but what we have
here is precisely that we've got to contort the interface with prepare.c
to do it that way.
(It also occurs to me that moving this work into the DestReceiver might
make things self-contained enough that we could continue to support
EXPLAIN SELECT INTO with not an undue amount of pain.)
Something else I just came across is that there are assorted places that
are aware that ExplainStmt contains a Query, eg setrefs.c, plancache.c,
and those have got to treat CreateTableAsStmt similarly. We could just
add more code in each of those places. I'm wondering though if it would
be a good idea to invent an abstraction layer, to wit a utility.c
function along the lines of "Query *UtilityContainsQuery(Node
*parsetree)", which would centralize the knowledge of exactly which
utility statements are like this and how to dig the Query out of them.
It's only marginally attractive unless there's a foreseeable reason
why we'd someday have more than two of them; but on the other hand,
just formalizing the concept that some utility statements are like
this might be a good thing. (Actually, as I type this I wonder whether
COPY (SELECT ...) isn't a member of this class too, and whether we don't
have bugs from the fact that it's not being treated like EXPLAIN.)
Thoughts?
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-16 22:17 ` Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-03-16 22:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> >> I'm thinking that if the table creation
> >> were to be moved into the tuple receiver's startup routine, we could
> >> avoid needing to get control back between ExecutorStartup and
> >> ExecutorRun, and then all that would be required would be to call
> >> ExecuteQuery with a different DestReceiver.
> >
> > Hm. I seriously dislike doing that in the receiver. I can't really point
> > out why though. Unsurprisingly I like getting the control back to
> > CreateTableAs...
>
> I don't see the argument. Receiver startup functions are intended to do
> exactly this type of thing. I'd be okay with leaving it in
> CreateTableAs if it didn't contort the code to do so, but what we have
> here is precisely that we've got to contort the interface with prepare.c
> to do it that way.
Hm.
> (It also occurs to me that moving this work into the DestReceiver might
> make things self-contained enough that we could continue to support
> EXPLAIN SELECT INTO with not an undue amount of pain.)
> Something else I just came across is that there are assorted places that
> are aware that ExplainStmt contains a Query, eg setrefs.c, plancache.c,
> and those have got to treat CreateTableAsStmt similarly.
Hm. Is that so? As implemented in my version the planner just sees a plain
statement instead of a utility statement. Am I missing something?
I am not even sure why the planner ever needs to see ExplainStmts? Protocol
level prepares? Shouldn't those top level nodes be simply removed once?
> We could just
> add more code in each of those places. I'm wondering though if it would
> be a good idea to invent an abstraction layer, to wit a utility.c
> function along the lines of "Query *UtilityContainsQuery(Node
> *parsetree)", which would centralize the knowledge of exactly which
> utility statements are like this and how to dig the Query out of them.
> It's only marginally attractive unless there's a foreseeable reason
> why we'd someday have more than two of them; but on the other hand,
> just formalizing the concept that some utility statements are like
> this might be a good thing.
If its really necessary to do that I think that would be a good idea. Alone
the increased greppablility/readablility seems to be worth it.
> (Actually, as I type this I wonder whether
> COPY (SELECT ...) isn't a member of this class too, and whether we don't
> have bugs from the fact that it's not being treated like EXPLAIN.)
> Thoughts?
Hm. On a first glance the planner also never sees the content of a CopyStmt...
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-17 15:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-17 15:02 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Andres Freund <andres@anarazel.de> writes:
> On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
>> Something else I just came across is that there are assorted places that
>> are aware that ExplainStmt contains a Query, eg setrefs.c, plancache.c,
>> and those have got to treat CreateTableAsStmt similarly.
> Hm. Is that so? As implemented in my version the planner just sees a plain
> statement instead of a utility statement. Am I missing something?
Well, the work flow for EXPLAIN is:
parse analysis: recursively do parse analysis on contained query
plan: do nothing
execution: call planner on contained query, then optionally run it
and the reason for doing it that way is explained by
transformExplainStmt:
* EXPLAIN is like other utility statements in that we emit it as a
* CMD_UTILITY Query node; however, we must first transform the contained
* query. We used to postpone that until execution, but it's really necessary
* to do it during the normal parse analysis phase to ensure that side effects
* of parser hooks happen at the expected time.
ISTM that argument applies just as much to CREATE TABLE AS, especially
in view of the fact that we're restructuring the SELECT INTO case, in
which parse analysis of the SELECT certainly does happen early. It's
also not clear to me why it wouldn't apply to COPY (SELECT ...).
I'm not going to touch the COPY (SELECT ...) issue right now, but
somebody ought to go back and check up on the exact user-visible bugs
that motivated moving EXPLAIN's parse analysis processing. (I suspect
it had to do with plpgsql variable processing, but too lazy to go look
right now.) If there's a plausible use case where similar bugs could
be exhibited in COPY, we're going to have to restructure that too.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-17 17:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 18:16 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-17 17:45 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
While looking at this I also noticed that DECLARE CURSOR uses a
structure that's randomly different in yet a third way: we start
with a utility statement containing a query, and then flip that
upside down so that the SELECT Query contains a utility statement!
I have a vague feeling that I'm the one who's guilty of that hack, too.
I'm not sure that anybody cares about being able to fire command
triggers on DECLARE CURSOR, but just from a consistency standpoint it
would make sense for this to work more like EXPLAIN and CREATE TABLE AS.
So that convinces me that UtilityContainsQuery() would be a good thing,
and I'll add that to the patch. (Actually changing DECLARE CURSOR seems
like a separate patch, though.)
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-17 18:16 ` Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-17 18:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Saturday, March 17, 2012 06:45:27 PM Tom Lane wrote:
> I'm not sure that anybody cares about being able to fire command
> triggers on DECLARE CURSOR
I actually think it would make sense to explicitly not fire command triggers
there given that DECLARE CURSOR actually potentially is somewhat performance
relevant.
> , but just from a consistency standpoint it
> would make sense for this to work more like EXPLAIN and CREATE TABLE AS.
> So that convinces me that UtilityContainsQuery() would be a good thing,
> and I'll add that to the patch. (Actually changing DECLARE CURSOR seems
> like a separate patch, though.)
Aggreed on that.
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-17 22:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 21:47 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
1 sibling, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-17 22:04 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
I've found a couple more issues in the CTAS patch:
1. Previous versions delivered a "SELECT n" command tag for either
spelling of the command:
regression=# select * into t1 from int8_tbl;
SELECT 6
regression=# create table t2 as select * from int8_tbl;
SELECT 6
With the patch I get
regression=# select * into t1 from int8_tbl;
SELECT 0 0
regression=# create table t2 as select * from int8_tbl;
CREATE TABLE AS
The first of these is particularly unfortunate since it's outright lying
as to the number of rows processed.
I'm not sure what we should do instead. We have gotten push-back before
anytime we changed the command tag for an existing command (and in fact
it seems that we intentionally added the rowcount display in 9.0, which
means there are people out there who care about that functionality).
On the other hand, the traditional output for CREATE TABLE AS doesn't
seem to satisfy the principle of least astonishment. A third
consideration is that if we are pushing CREATE TABLE AS as the preferred
spelling, people will probably complain if it omits functionality that
SELECT INTO provides; so I'm not sure that "SELECT n" in one case and
"CREATE TABLE AS" in the other would be a good idea either. Any
opinions what to do here?
2. Historically, CREATE RULE has allowed a rule action to be SELECT INTO
(though not CREATE TABLE AS). Currently the patch is throwing an error
for that. This seems like something that might not be worth fixing,
though. It's fairly hard to conceive of a use-case for such a rule,
since it would work only once before starting to throw "table already
exists" errors. How much do we care about preserving backward
compatibility here?
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-17 22:26 ` Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-03-17 22:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Saturday, March 17, 2012 11:04:30 PM Tom Lane wrote:
> I've found a couple more issues in the CTAS patch:
>
> 1. Previous versions delivered a "SELECT n" command tag for either
> spelling of the command:
>
> regression=# select * into t1 from int8_tbl;
> SELECT 6
> regression=# create table t2 as select * from int8_tbl;
> SELECT 6
>
> With the patch I get
>
> regression=# select * into t1 from int8_tbl;
> SELECT 0 0
hm. Stupid me.
> regression=# create table t2 as select * from int8_tbl;
> CREATE TABLE AS
>
> The first of these is particularly unfortunate since it's outright lying
> as to the number of rows processed.
> I'm not sure what we should do instead. We have gotten push-back before
> anytime we changed the command tag for an existing command (and in fact
> it seems that we intentionally added the rowcount display in 9.0, which
> means there are people out there who care about that functionality).
> On the other hand, the traditional output for CREATE TABLE AS doesn't
> seem to satisfy the principle of least astonishment. A third
> consideration is that if we are pushing CREATE TABLE AS as the preferred
> spelling, people will probably complain if it omits functionality that
> SELECT INTO provides; so I'm not sure that "SELECT n" in one case and
> "CREATE TABLE AS" in the other would be a good idea either. Any
> opinions what to do here?
I would prefer both returning CREATE TABLE AS since thats what actually
happens. We already document that SELECT INTO is kinda deprecated: "The
PostgreSQL usage of SELECT INTO to represent table creation is historical. It
is best to use CREATE TABLE AS for this purpose in new code."
I have seen code that uses the command code for selecting the, app level,
logging. Its kinda hard to do that if a CREATE TABLE AS/SELECT INTO returns
SELECT.
Does CTAS ommit any functionality currently? I don't see any reason not to
support stuff there thats supported in SELECT INTO.
> 2. Historically, CREATE RULE has allowed a rule action to be SELECT INTO
> (though not CREATE TABLE AS). Currently the patch is throwing an error
> for that. This seems like something that might not be worth fixing,
> though. It's fairly hard to conceive of a use-case for such a rule,
> since it would work only once before starting to throw "table already
> exists" errors. How much do we care about preserving backward
> compatibility here?
I vote for not supporting that anymore. That being possible looks more like an
implementation detail to me.
Thanks for looking at this!
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-18 18:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 19:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-19 13:13 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-19 16:35 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 3 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-18 18:29 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with that receiver. It appears that we still need at
least two bits of added complexity with that approach:
1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query is a SELECT. (BTW, maybe
this should be weakened to "something that returns tuples", in view of
RETURNING?)
2. Since ExecuteQuery goes through the Portal machinery, there's no way
for it to pass in eflags to control the table OIDs setup. This is
easily solved by adding an eflags parameter to PortalStart, which
doesn't seem too awful to me, since the typical caller would just pass
zero. (ExecuteQuery would also have to know about testing
interpretOidsOption to compute the eflags to use, unless we add an
eflags parameter to it, which might be the cleaner option.)
In short I'm thinking: add an eflags parameter to PortalStart, and add
both an eflags parameter and a "bool mustReturnTuples" parameter to
ExecuteQuery. This definitely seems cleaner than the current
duplication of code.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-18 19:12 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-19 01:11 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-18 19:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
That lights a bulb: what about rewriting CREATE TABLE AS as two
commands, internally:
1. CREATE TABLE …
2. WITH x ( <query here> ) INSERT INTO … SELECT * FROM x;
It seems like not solving much from a practical point of view though as
you need to be able to parse the output of the subquery before you can
do the first step, but on the other hand it might be that you already
have the pieces to just do that.
Well, I had to share that though, somehow.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 19:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-19 01:11 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-19 01:11 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> That lights a bulb: what about rewriting CREATE TABLE AS as two
> commands, internally:
Given the compatibility constraints on issues like what command tag
to return, I think that would probably make our jobs harder not easier.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-19 13:13 ` Andres Freund <andres@anarazel.de>
2 siblings, 0 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-19 13:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Sunday, March 18, 2012 07:29:30 PM Tom Lane wrote:
> BTW, I've been looking through how to do what I suggested earlier to get
> rid of the coziness and code duplication between CreateTableAs and the
> prepare.c code; namely, let CreateTableAs create a DestReceiver and then
> call ExecuteQuery with that receiver. It appears that we still need at
> least two bits of added complexity with that approach:
>
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
I don't really see the use case but given the amount of work it probably takes
it seems reasonable to allow that.
> 2. Since ExecuteQuery goes through the Portal machinery, there's no way
> for it to pass in eflags to control the table OIDs setup. This is
> easily solved by adding an eflags parameter to PortalStart, which
> doesn't seem too awful to me, since the typical caller would just pass
> zero. (ExecuteQuery would also have to know about testing
> interpretOidsOption to compute the eflags to use, unless we add an
> eflags parameter to it, which might be the cleaner option.)
If we go down this route I think adding an eflag is the better choice. Thinking
of it - my patch already added that ;)
> In short I'm thinking: add an eflags parameter to PortalStart, and add
> both an eflags parameter and a "bool mustReturnTuples" parameter to
> ExecuteQuery. This definitely seems cleaner than the current
> duplication of code.
Hm. I am not *that* convinced anymore. It wasn't that much duplication in the
end...
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-19 16:35 ` Robert Haas <robertmhaas@gmail.com>
2012-03-19 16:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-19 16:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
> that it can enforce that the prepared query is a SELECT. (BTW, maybe
> this should be weakened to "something that returns tuples", in view of
> RETURNING?)
+1 for "something that returns with tuples". CREATE TABLE ... AS
DELETE FROM ... WHERE ... RETURNING ... seems like a cool thing to
support.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:35 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-19 16:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:52 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-19 16:45 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
>> that it can enforce that the prepared query is a SELECT. (BTW, maybe
>> this should be weakened to "something that returns tuples", in view of
>> RETURNING?)
> +1 for "something that returns with tuples". CREATE TABLE ... AS
> DELETE FROM ... WHERE ... RETURNING ... seems like a cool thing to
> support.
For the moment I've backed off that idea. The main definitional
question we'd have to resolve is whether we want to allow WITH NO DATA,
and if so what does that mean (should the DELETE execute, or not?).
I am also not certain that the RETURNING code paths would cope with
a WITH OIDS specification, and there are some other things that would
need fixed. It might be cool to do it sometime, but it's not going to
happen in this patch.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:35 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-19 16:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-19 16:52 ` Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-19 16:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Mon, Mar 19, 2012 at 12:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Mar 18, 2012 at 2:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
>>> that it can enforce that the prepared query is a SELECT. (BTW, maybe
>>> this should be weakened to "something that returns tuples", in view of
>>> RETURNING?)
>
>> +1 for "something that returns with tuples". CREATE TABLE ... AS
>> DELETE FROM ... WHERE ... RETURNING ... seems like a cool thing to
>> support.
>
> For the moment I've backed off that idea. The main definitional
> question we'd have to resolve is whether we want to allow WITH NO DATA,
> and if so what does that mean (should the DELETE execute, or not?).
> I am also not certain that the RETURNING code paths would cope with
> a WITH OIDS specification, and there are some other things that would
> need fixed. It might be cool to do it sometime, but it's not going to
> happen in this patch.
Fair enough. It would be nice to have, but it definitely does not
seem worth spending a lot of time on right now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-18 21:47 ` Peter Eisentraut <peter_e@gmx.net>
2012-03-19 01:16 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 115+ messages in thread
From: Peter Eisentraut @ 2012-03-18 21:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
> I'm not sure what we should do instead. We have gotten push-back before
> anytime we changed the command tag for an existing command (and in fact
> it seems that we intentionally added the rowcount display in 9.0, which
> means there are people out there who care about that functionality).
> On the other hand, the traditional output for CREATE TABLE AS doesn't
> seem to satisfy the principle of least astonishment. A third
> consideration is that if we are pushing CREATE TABLE AS as the preferred
> spelling, people will probably complain if it omits functionality that
> SELECT INTO provides; so I'm not sure that "SELECT n" in one case and
> "CREATE TABLE AS" in the other would be a good idea either. Any
> opinions what to do here?
Another consideration is that the SQL command tags are defined by the
SQL standard. So if we were to change it, then it should be "CREATE
TABLE". I'm not convinced that it should be changed, though. (I recall
cross-checking our list against the SQL standard in the past, so there
might have been discussion on this already.)
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 21:47 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
@ 2012-03-19 01:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:53 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-19 01:16 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2012-03-17 at 18:04 -0400, Tom Lane wrote:
>> I'm not sure what we should do instead. We have gotten push-back before
>> anytime we changed the command tag for an existing command (and in fact
>> it seems that we intentionally added the rowcount display in 9.0, which
>> means there are people out there who care about that functionality).
>> On the other hand, the traditional output for CREATE TABLE AS doesn't
>> seem to satisfy the principle of least astonishment. A third
>> consideration is that if we are pushing CREATE TABLE AS as the preferred
>> spelling, people will probably complain if it omits functionality that
>> SELECT INTO provides; so I'm not sure that "SELECT n" in one case and
>> "CREATE TABLE AS" in the other would be a good idea either. Any
>> opinions what to do here?
> Another consideration is that the SQL command tags are defined by the
> SQL standard. So if we were to change it, then it should be "CREATE
> TABLE". I'm not convinced that it should be changed, though. (I recall
> cross-checking our list against the SQL standard in the past, so there
> might have been discussion on this already.)
If we were going to change the output at all, I would vote for "CREATE
TABLE nnnn" so as to preserve the rowcount functionality. Keep in mind
though that this would force client-side changes, for instance in
libpq's PQcmdTuples(). Fixing that one routine isn't so painful, but
what of other client-side libraries, not to mention applications?
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 21:47 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
2012-03-19 01:16 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-19 16:53 ` Peter Eisentraut <peter_e@gmx.net>
2012-03-19 17:06 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 115+ messages in thread
From: Peter Eisentraut @ 2012-03-19 16:53 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
> If we were going to change the output at all, I would vote for "CREATE
> TABLE nnnn" so as to preserve the rowcount functionality. Keep in
> mind though that this would force client-side changes, for instance in
> libpq's PQcmdTuples(). Fixing that one routine isn't so painful, but
> what of other client-side libraries, not to mention applications?
Doesn't seem worth it to me. At least, "SELECT nnnn" makes some sense:
nnnn rows were selected. "CREATE TABLE nnnn" means what? nnnn tables
were created?
What might make sense is to delegate this additional information to
separate fields in a future protocol revision.
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 21:47 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
2012-03-19 01:16 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:53 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
@ 2012-03-19 17:06 ` Robert Haas <robertmhaas@gmail.com>
2012-03-19 18:10 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-19 17:06 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On sön, 2012-03-18 at 21:16 -0400, Tom Lane wrote:
>> If we were going to change the output at all, I would vote for "CREATE
>> TABLE nnnn" so as to preserve the rowcount functionality. Keep in
>> mind though that this would force client-side changes, for instance in
>> libpq's PQcmdTuples(). Fixing that one routine isn't so painful, but
>> what of other client-side libraries, not to mention applications?
>
> Doesn't seem worth it to me. At least, "SELECT nnnn" makes some sense:
> nnnn rows were selected. "CREATE TABLE nnnn" means what? nnnn tables
> were created?
>
> What might make sense is to delegate this additional information to
> separate fields in a future protocol revision.
I think that we would not have bothered to add the row count to the
command tag output for SELECT unless it were useful. It seems to be
*more* useful for CTAS than for SELECT; after all, SELECT also returns
the actual rows.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:04 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 21:47 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
2012-03-19 01:16 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:53 ` Re: Command Triggers, patch v11 Peter Eisentraut <peter_e@gmx.net>
2012-03-19 17:06 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-19 18:10 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-19 18:10 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Peter Eisentraut <peter_e@gmx.net>; Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 19, 2012 at 12:53 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> Doesn't seem worth it to me. At least, "SELECT nnnn" makes some sense:
>> nnnn rows were selected. "CREATE TABLE nnnn" means what? nnnn tables
>> were created?
>>
>> What might make sense is to delegate this additional information to
>> separate fields in a future protocol revision.
> I think that we would not have bothered to add the row count to the
> command tag output for SELECT unless it were useful. It seems to be
> *more* useful for CTAS than for SELECT; after all, SELECT also returns
> the actual rows.
I think we're all in agreement that we need to keep the rowcount
functionality. What seems to me to be in some doubt is whether to
continue to present the tag "SELECT nnnn" or to change it to something
like "CREATE TABLE nnnn". For the moment I've got the patch doing the
former. It would not be terribly hard to change it, but I'm not going
to break backward compatibility unless there's a pretty clear consensus
to do so.
BTW, I just came across another marginal-loss-of-functionality issue:
in previous versions you could PREPARE a SELECT INTO, but now you get
regression=# prepare foo as select * into bar from int8_tbl;
ERROR: utility statements cannot be prepared
Is anybody excited about that? If it is something we have to keep,
it seems like pretty nearly a deal-breaker for this patch, because
storing a CreateTableAsStmt containing an already-prepared plan would
complicate matters unreasonably. You can still get approximately
the same result with
prepare foo as select * from int8_tbl;
create table bar as execute foo;
which if anything is more useful since you didn't nail down the target
table name in the PREPARE, but nonetheless it's different.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-19 18:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 01:39 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-03-19 18:51 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; pgsql-hackers; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
I wrote:
> One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
While I'm not particularly excited about fixing PREPARE ... SELECT INTO
or CREATE RULE ... SELECT INTO, I've come to the conclusion that the
EXPLAIN case is a must-fix. Because not only is EXPLAIN SELECT INTO
broken, but so is EXPLAIN CREATE TABLE AS, and the latter functionality
is actually documented. So presumably somebody went out of their way
to make this work, at some point.
Since I've got the table-creation code moved into intorel_startup,
this doesn't look to be that painful, but it will require an API change
for ExplainOnePlan, which is slightly annoying because that's probably
in use by third-party plugins. We could either break them obviously
(by adding an explicit parameter) or break them subtly (by adding an
ExplainState field they might forget to initialize). The former seems
preferable.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 18:51 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-20 01:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 15:55 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-20 17:44 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-03-20 01:39 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
I've applied the CTAS patch after rather heavy editorialization. Don't
know what consequences that will have for Dimitri's patch.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 18:51 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 01:39 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-20 15:55 ` Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-20 15:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Tuesday, March 20, 2012 02:39:56 AM Tom Lane wrote:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
Thanks for all the work you put into this! Looks cleaner now...
Thanks,
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-02 22:32 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-16 20:54 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 18:51 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 01:39 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-20 17:44 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-20 17:44 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> I've applied the CTAS patch after rather heavy editorialization. Don't
> know what consequences that will have for Dimitri's patch.
It allows my patch to add support for CREATE TABLE AS and SELECT INTO,
I've been doing that and am on my way to sending a v18 now. The way you
worked out the command tag is exactly what I needed, so thanks a lot for
your work comitting this and paying attention :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 12:00 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-25 12:00 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Hi,
Please find attached version 12 of the patch, which is fixing docs per
your review. Thanks for your time, comments and fixes!
You can see the patch-on-patch here for quick proof reading:
https://github.com/dimitri/postgres/commit/b7798e8ba6c9bee1f65b233316ae9c08b78e5ddb
Thom Brown <thom@linux.com> writes:
> I just tried building the docs with your patch and it appears
> doc/src/sgml/ref/allfiles.sgml hasn't been updated with the necessary
> references for alterCommandTrigger, createCommandTrigger and
> dropCommandTrigger.
>
> Also in ref/alter_command_trigger.sgml, you define SQL-CREATETRIGGER.
> Shouldn't this be SQL-CREATECOMMANDTRIGGER? And there also appears to
> be orphaned text in the file too, such as "Forbids the execution of
> any DDL command". And there's a stray </para> on line 299.
>
> I attach updated versions of both of those files, which seems to fix
> all these problems.
Those are in the attached, apart from your editing of the examples para.
A single para is needed around all examples, which was forgotten in my
previous version of the patch, now fixed.
Thom Brown <thom@linux.com> writes:
> I've just noticed there's an issue with
> doc/src/sgml/ref/alter_command_trigger.sgml too. It uses <indexterm
> zone="sql-altertrigger"> which should be sql-altercommandtrigger. (as
> attached)
Included.
Thom Brown <thom@linux.com> writes:
> And upon trying to test the actual feature, it didn't work for me at
> all. I thought I had applied the patch incorrectly, but I hadn't, it
> was the documentation showing the wrong information. The CREATE
> COMMAND TRIGGER page actually just says CREATE TRIGGER.... BEFORE
> COMMAND <command>, which isn't the correct syntax.
Seems like I've forgotten to update the docs when acting on Robert's
suggestion to improve the syntax to CREATE COMMAND TRIGGER. I've now
fixed that.
> Also the examples on the page are incorrect in the same regard. When
> I tested it with the correction, I got an error saying that the
> function used had to return void, but the example uses bool. Upon
> also changing this, the example works as expected.
Fixed too.
Thom Brown <thom@linux.com> writes:
> Is there any reason why the list of commands that command triggers can
> be used with isn't in alphabetical order? Also it appears to show
Any reason why? I don't suppose it's really important one way or the
other, so I'm waiting on some more voices before working on it.
> CREATE/ALTER/DROP TYPE_P, and the same for CONVERSION_P and DOMAIN_P.
> I'm assuming these are typos? They also appear on DROP COMMAND
> TRIGGER.
Yeah I did use an emacs macro to get from the gram.y format to the docs
format, then replaced '_P ' with ''. Should have replaced '_P' really,
now done.
> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
> be used against. Perhaps, rather than repeat the list, there could be
> a note to say that a list of valid commands can be found on the CREATE
> COMMAND TRIGGER page?
Well you can only alter a command that you were successful in creating,
right? So I'm not sure that's needed here. By that count though, I
maybe should remove the supported command list from DROP COMMAND TRIGGER
reference page?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
command-trigger.v12.patch.gz (application/octet-stream, 58.5K) download
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-25 12:07 ` Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-25 12:07 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
D'oh, just as I sent some more queries...
> Thom Brown <thom@linux.com> writes:
>> Is there any reason why the list of commands that command triggers can
>> be used with isn't in alphabetical order? Also it appears to show
>
> Any reason why? I don't suppose it's really important one way or the
> other, so I'm waiting on some more voices before working on it.
Just so it's easy to scan. If someone is looking for CREATE CAST,
they'd kind of expect it near the drop of the CREATE list, but it's
actually toward the bottom. It just looks random at the moment.
>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>> be used against. Perhaps, rather than repeat the list, there could be
>> a note to say that a list of valid commands can be found on the CREATE
>> COMMAND TRIGGER page?
>
> Well you can only alter a command that you were successful in creating,
> right? So I'm not sure that's needed here. By that count though, I
> maybe should remove the supported command list from DROP COMMAND TRIGGER
> reference page?
Sure, that would be more consistent. You're right, it's not needed.
It just seemed odd that one of the statements lacked what both others
had.
Thanks
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 12:42 ` Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-25 12:42 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>
> D'oh, just as I sent some more queries...
>
>> Thom Brown <thom@linux.com> writes:
>>> Is there any reason why the list of commands that command triggers can
>>> be used with isn't in alphabetical order? Also it appears to show
>>
>> Any reason why? I don't suppose it's really important one way or the
>> other, so I'm waiting on some more voices before working on it.
>
> Just so it's easy to scan. If someone is looking for CREATE CAST,
> they'd kind of expect it near the drop of the CREATE list, but it's
> actually toward the bottom. It just looks random at the moment.
>
>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>> be used against. Perhaps, rather than repeat the list, there could be
>>> a note to say that a list of valid commands can be found on the CREATE
>>> COMMAND TRIGGER page?
>>
>> Well you can only alter a command that you were successful in creating,
>> right? So I'm not sure that's needed here. By that count though, I
>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>> reference page?
>
> Sure, that would be more consistent. You're right, it's not needed.
> It just seemed odd that one of the statements lacked what both others
> had.
Yet another comment... (I should have really started looking at this
at an earlier stage)
It seems that if one were to enforce a naming convention for relations
as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
circumvented by someone using CREATE TABLE name AS...
test=# CREATE TABLE badname (id int, a int, b text);
ERROR: invalid relation name: badname
test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
SELECT 1
This doesn't even get picked up by ANY COMMAND.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 13:15 ` Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-25 13:15 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 12:42, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
>> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>
>> D'oh, just as I sent some more queries...
>>
>>> Thom Brown <thom@linux.com> writes:
>>>> Is there any reason why the list of commands that command triggers can
>>>> be used with isn't in alphabetical order? Also it appears to show
>>>
>>> Any reason why? I don't suppose it's really important one way or the
>>> other, so I'm waiting on some more voices before working on it.
>>
>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>> they'd kind of expect it near the drop of the CREATE list, but it's
>> actually toward the bottom. It just looks random at the moment.
>>
>>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>>> be used against. Perhaps, rather than repeat the list, there could be
>>>> a note to say that a list of valid commands can be found on the CREATE
>>>> COMMAND TRIGGER page?
>>>
>>> Well you can only alter a command that you were successful in creating,
>>> right? So I'm not sure that's needed here. By that count though, I
>>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>>> reference page?
>>
>> Sure, that would be more consistent. You're right, it's not needed.
>> It just seemed odd that one of the statements lacked what both others
>> had.
>
> Yet another comment... (I should have really started looking at this
> at an earlier stage)
>
> It seems that if one were to enforce a naming convention for relations
> as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
> circumvented by someone using CREATE TABLE name AS...
>
> test=# CREATE TABLE badname (id int, a int, b text);
> ERROR: invalid relation name: badname
> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> SELECT 1
>
> This doesn't even get picked up by ANY COMMAND.
CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
expect ALTER COMMAND TRIGGER to output too for when individual
commands are disabled etc.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 13:28 ` Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Thom Brown @ 2012-02-25 13:28 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 13:15, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 12:42, Thom Brown <thom@linux.com> wrote:
>> On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
>>> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>
>>> D'oh, just as I sent some more queries...
>>>
>>>> Thom Brown <thom@linux.com> writes:
>>>>> Is there any reason why the list of commands that command triggers can
>>>>> be used with isn't in alphabetical order? Also it appears to show
>>>>
>>>> Any reason why? I don't suppose it's really important one way or the
>>>> other, so I'm waiting on some more voices before working on it.
>>>
>>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>>> they'd kind of expect it near the drop of the CREATE list, but it's
>>> actually toward the bottom. It just looks random at the moment.
>>>
>>>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>>>> be used against. Perhaps, rather than repeat the list, there could be
>>>>> a note to say that a list of valid commands can be found on the CREATE
>>>>> COMMAND TRIGGER page?
>>>>
>>>> Well you can only alter a command that you were successful in creating,
>>>> right? So I'm not sure that's needed here. By that count though, I
>>>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>>>> reference page?
>>>
>>> Sure, that would be more consistent. You're right, it's not needed.
>>> It just seemed odd that one of the statements lacked what both others
>>> had.
>>
>> Yet another comment... (I should have really started looking at this
>> at an earlier stage)
>>
>> It seems that if one were to enforce a naming convention for relations
>> as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
>> circumvented by someone using CREATE TABLE name AS...
>>
>> test=# CREATE TABLE badname (id int, a int, b text);
>> ERROR: invalid relation name: badname
>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>> SELECT 1
>>
>> This doesn't even get picked up by ANY COMMAND.
>
> CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
> expect ALTER COMMAND TRIGGER to output too for when individual
> commands are disabled etc.
Just found another case where a table can be created without a command
trigger firing:
SELECT * INTO badname FROM goodname;
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 14:30 ` Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-25 14:30 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 13:28, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 13:15, Thom Brown <thom@linux.com> wrote:
>> On 25 February 2012 12:42, Thom Brown <thom@linux.com> wrote:
>>> On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
>>>> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>
>>>> D'oh, just as I sent some more queries...
>>>>
>>>>> Thom Brown <thom@linux.com> writes:
>>>>>> Is there any reason why the list of commands that command triggers can
>>>>>> be used with isn't in alphabetical order? Also it appears to show
>>>>>
>>>>> Any reason why? I don't suppose it's really important one way or the
>>>>> other, so I'm waiting on some more voices before working on it.
>>>>
>>>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>>>> they'd kind of expect it near the drop of the CREATE list, but it's
>>>> actually toward the bottom. It just looks random at the moment.
>>>>
>>>>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>>>>> be used against. Perhaps, rather than repeat the list, there could be
>>>>>> a note to say that a list of valid commands can be found on the CREATE
>>>>>> COMMAND TRIGGER page?
>>>>>
>>>>> Well you can only alter a command that you were successful in creating,
>>>>> right? So I'm not sure that's needed here. By that count though, I
>>>>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>>>>> reference page?
>>>>
>>>> Sure, that would be more consistent. You're right, it's not needed.
>>>> It just seemed odd that one of the statements lacked what both others
>>>> had.
>>>
>>> Yet another comment... (I should have really started looking at this
>>> at an earlier stage)
>>>
>>> It seems that if one were to enforce a naming convention for relations
>>> as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
>>> circumvented by someone using CREATE TABLE name AS...
>>>
>>> test=# CREATE TABLE badname (id int, a int, b text);
>>> ERROR: invalid relation name: badname
>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>> SELECT 1
>>>
>>> This doesn't even get picked up by ANY COMMAND.
>>
>> CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
>> expect ALTER COMMAND TRIGGER to output too for when individual
>> commands are disabled etc.
>
> Just found another case where a table can be created without a command
> trigger firing:
>
> SELECT * INTO badname FROM goodname;
Right, hopefully this should be my last piece of list spam for the
time being. (apologies, I thought I'd just try it out at first, but
it's ended up being reviewed piecemeal)
On CREATE COMMAND TRIGGER page:
“The trigger will be associated with the specified command and will
execute the specified function function_name when that command is
run.”
should be:
“The trigger will be associated with the specified commands and will
execute the specified function function_name when those commands are
run.”
“A command trigger's function must return void, the only it can aborts
the execution of the command is by raising an exception.”
should be:
“A command trigger's function must return void. It can then only
abort the execution of the command by raising an exception.”
Remove:
“For a constraint trigger, this is also the name to use when modifying
the trigger's behavior using SET CONSTRAINTS.”
Remove:
“That leaves out the following list of non supported commands.”
s/exercize/exercise/
“that's the case for VACUUM, CLUSTER CREATE INDEX CONCURRENTLY, and
REINDEX DATABASE.”
should be:
“that's the case for VACUUM, CLUSTER, CREATE INDEX CONCURRENTLY, and
REINDEX DATABASE.”
I don’t understand this sentence:
“Triggers on ANY command support more commands than just this list,
and will only provide the command tag argument as NOT NULL.”
On ALTER COMMAND TRIGGER page:
“ALTER COMMAND TRIGGER name ON command SET enabled”
should be:
“ALTER COMMAND TRIGGER name ON command [, ... ] SET enabled”
On DROP COMMAND TRIGGER page:
There’s a mention of CASCADE and RESTRICT. I don’t know of any object
which could be dependant on a command trigger, so I don’t see what
these are for.
An oddity I’ve noticed is that you can add additional commands to an
existing command trigger, and you can also have them execute a
different function to the other commands referenced in the same
trigger.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-25 16:36 ` Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-25 16:36 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 14:30, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 13:28, Thom Brown <thom@linux.com> wrote:
>> On 25 February 2012 13:15, Thom Brown <thom@linux.com> wrote:
>>> On 25 February 2012 12:42, Thom Brown <thom@linux.com> wrote:
>>>> On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
>>>>> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>>
>>>>> D'oh, just as I sent some more queries...
>>>>>
>>>>>> Thom Brown <thom@linux.com> writes:
>>>>>>> Is there any reason why the list of commands that command triggers can
>>>>>>> be used with isn't in alphabetical order? Also it appears to show
>>>>>>
>>>>>> Any reason why? I don't suppose it's really important one way or the
>>>>>> other, so I'm waiting on some more voices before working on it.
>>>>>
>>>>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>>>>> they'd kind of expect it near the drop of the CREATE list, but it's
>>>>> actually toward the bottom. It just looks random at the moment.
>>>>>
>>>>>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>>>>>> be used against. Perhaps, rather than repeat the list, there could be
>>>>>>> a note to say that a list of valid commands can be found on the CREATE
>>>>>>> COMMAND TRIGGER page?
>>>>>>
>>>>>> Well you can only alter a command that you were successful in creating,
>>>>>> right? So I'm not sure that's needed here. By that count though, I
>>>>>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>>>>>> reference page?
>>>>>
>>>>> Sure, that would be more consistent. You're right, it's not needed.
>>>>> It just seemed odd that one of the statements lacked what both others
>>>>> had.
>>>>
>>>> Yet another comment... (I should have really started looking at this
>>>> at an earlier stage)
>>>>
>>>> It seems that if one were to enforce a naming convention for relations
>>>> as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
>>>> circumvented by someone using CREATE TABLE name AS...
>>>>
>>>> test=# CREATE TABLE badname (id int, a int, b text);
>>>> ERROR: invalid relation name: badname
>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>>> SELECT 1
>>>>
>>>> This doesn't even get picked up by ANY COMMAND.
>>>
>>> CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
>>> expect ALTER COMMAND TRIGGER to output too for when individual
>>> commands are disabled etc.
>>
>> Just found another case where a table can be created without a command
>> trigger firing:
>>
>> SELECT * INTO badname FROM goodname;
>
> Right, hopefully this should be my last piece of list spam for the
> time being. (apologies, I thought I'd just try it out at first, but
> it's ended up being reviewed piecemeal)
I was wrong.. a couple of corrections to my own response:
> On CREATE COMMAND TRIGGER page:
>
> “The trigger will be associated with the specified command and will
> execute the specified function function_name when that command is
> run.”
> should be:
> “The trigger will be associated with the specified commands and will
> execute the specified function function_name when those commands are
> run.”
Actually, perhaps "...when any of those commands..."
> On ALTER COMMAND TRIGGER page:
>
> “ALTER COMMAND TRIGGER name ON command SET enabled”
> should be:
> “ALTER COMMAND TRIGGER name ON command [, ... ] SET enabled”
This one is nonsense, so please ignore it.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-26 00:07 ` Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-26 00:07 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 25 February 2012 16:36, Thom Brown <thom@linux.com> wrote:
> On 25 February 2012 14:30, Thom Brown <thom@linux.com> wrote:
>> On 25 February 2012 13:28, Thom Brown <thom@linux.com> wrote:
>>> On 25 February 2012 13:15, Thom Brown <thom@linux.com> wrote:
>>>> On 25 February 2012 12:42, Thom Brown <thom@linux.com> wrote:
>>>>> On 25 February 2012 12:07, Thom Brown <thom@linux.com> wrote:
>>>>>> On 25 February 2012 12:00, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>>>>>>
>>>>>> D'oh, just as I sent some more queries...
>>>>>>
>>>>>>> Thom Brown <thom@linux.com> writes:
>>>>>>>> Is there any reason why the list of commands that command triggers can
>>>>>>>> be used with isn't in alphabetical order? Also it appears to show
>>>>>>>
>>>>>>> Any reason why? I don't suppose it's really important one way or the
>>>>>>> other, so I'm waiting on some more voices before working on it.
>>>>>>
>>>>>> Just so it's easy to scan. If someone is looking for CREATE CAST,
>>>>>> they'd kind of expect it near the drop of the CREATE list, but it's
>>>>>> actually toward the bottom. It just looks random at the moment.
>>>>>>
>>>>>>>> The ALTER COMMAND TRIGGER page also doesn't show which commands it can
>>>>>>>> be used against. Perhaps, rather than repeat the list, there could be
>>>>>>>> a note to say that a list of valid commands can be found on the CREATE
>>>>>>>> COMMAND TRIGGER page?
>>>>>>>
>>>>>>> Well you can only alter a command that you were successful in creating,
>>>>>>> right? So I'm not sure that's needed here. By that count though, I
>>>>>>> maybe should remove the supported command list from DROP COMMAND TRIGGER
>>>>>>> reference page?
>>>>>>
>>>>>> Sure, that would be more consistent. You're right, it's not needed.
>>>>>> It just seemed odd that one of the statements lacked what both others
>>>>>> had.
>>>>>
>>>>> Yet another comment... (I should have really started looking at this
>>>>> at an earlier stage)
>>>>>
>>>>> It seems that if one were to enforce a naming convention for relations
>>>>> as shown in the 2nd example for CREATE COMMAND TRIGGER, it could be
>>>>> circumvented by someone using CREATE TABLE name AS...
>>>>>
>>>>> test=# CREATE TABLE badname (id int, a int, b text);
>>>>> ERROR: invalid relation name: badname
>>>>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>>>>> SELECT 1
>>>>>
>>>>> This doesn't even get picked up by ANY COMMAND.
>>>>
>>>> CREATE COMMAND TRIGGER doesn't output in pg_dump or pg_dumpall. I'd
>>>> expect ALTER COMMAND TRIGGER to output too for when individual
>>>> commands are disabled etc.
>>>
>>> Just found another case where a table can be created without a command
>>> trigger firing:
>>>
>>> SELECT * INTO badname FROM goodname;
>>
>> Right, hopefully this should be my last piece of list spam for the
>> time being. (apologies, I thought I'd just try it out at first, but
>> it's ended up being reviewed piecemeal)
>
> I was wrong.. a couple of corrections to my own response:
>
>> On CREATE COMMAND TRIGGER page:
>>
>> “The trigger will be associated with the specified command and will
>> execute the specified function function_name when that command is
>> run.”
>> should be:
>> “The trigger will be associated with the specified commands and will
>> execute the specified function function_name when those commands are
>> run.”
>
> Actually, perhaps "...when any of those commands..."
>
>> On ALTER COMMAND TRIGGER page:
>>
>> “ALTER COMMAND TRIGGER name ON command SET enabled”
>> should be:
>> “ALTER COMMAND TRIGGER name ON command [, ... ] SET enabled”
>
> This one is nonsense, so please ignore it.
Further testing reveals a problem with FTS configurations when using
the example function provided in the docs:
test=# CREATE TEXT SEARCH CONFIGURATION test (
PARSER = "default"
);
ERROR: invalid relation name:
test=# CREATE TEXT SEARCH CONFIGURATION fr_test (
PARSER = "default"
);
ERROR: invalid relation name:
The 2nd one should work as it matches the naming convention checked in
the function. The ALTER and DROP equivalents appear to be fine
though.
DROP CAST shares a similar issue too:
test=# DROP CAST (bigint as int4);
ERROR: invalid relation name: �
The odd thing about this one is that CREATE CAST shouldn't match on
name at all, but it creates a cast successfully, whereas DROP CAST
disagrees with the name.
Command triggers for CREATE TYPE don't work, but fine for ALTER TYPE
and DROP TYPE.
Also command triggers for DROP CONVERSION aren't working. A glance at
pg_cmdtrigger shows that the system views the command as "DROP
CONVERSION_P".
What is DROP ASSERTION? It's showing as a valid command for a command
trigger, but it's not documented.
I've noticed that ALTER <object> name OWNER TO role doesn't result in
any trigger being fired except for tables.
ALTER OPERATOR FAMILY .... RENAME TO ... doesn't fire command triggers.
ALTER OPERATOR CLASS with RENAME TO or OWNER TO doesn't fire command
triggers, but with SET SCHEMA it does.
And there's no command trigger available for ALTER VIEW.
I'll hold off on testing any further until a new patch is available.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-26 14:12 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-26 14:12 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thanks for your further testing!
Thom Brown <thom@linux.com> writes:
> Further testing reveals a problem with FTS configurations when using
> the example function provided in the docs:
Could you send me your tests so that I add them to the proper regression
test? I've been lazy on one or two object types and obviously that's
where I have to check some more.
> Also command triggers for DROP CONVERSION aren't working. A glance at
> pg_cmdtrigger shows that the system views the command as "DROP
> CONVERSION_P".
That's easy to fix, that's a typo in gram.y. I'm not seeing other ones
like this though.
- | DROP CONVERSION_P { $$ = "DROP CONVERSION_P"; }
+ | DROP CONVERSION_P { $$ = "DROP CONVERSION"; }
> What is DROP ASSERTION? It's showing as a valid command for a command
> trigger, but it's not documented.
It's a Not Implemented Feature for which we have the grammar support to
be able to fill a standard compliant checkbox, or something like that.
It could be better for me to remove explicit support for it in the
command triggers patch?
> I've noticed that ALTER <object> name OWNER TO role doesn't result in
> any trigger being fired except for tables.
>
> ALTER OPERATOR FAMILY .... RENAME TO ... doesn't fire command triggers.
>
> ALTER OPERATOR CLASS with RENAME TO or OWNER TO doesn't fire command
> triggers, but with SET SCHEMA it does.
It seems I've forgotten to add some support here, that happens in
alter.c and is easy enough to check and complete, thanks for the
testing.
> And there's no command trigger available for ALTER VIEW.
Will add.
> I'll hold off on testing any further until a new patch is available.
That should happen soon. Ah, the joys of coding while kids are at home
thanks to school holidays. I can't count how many times I've been killed
by a captain and married to a princess while writing that patch, sorry
about those hiccups here.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-26 19:49 ` Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-26 19:49 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 26 February 2012 14:12, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Thanks for your further testing!
>
> Thom Brown <thom@linux.com> writes:
>> Further testing reveals a problem with FTS configurations when using
>> the example function provided in the docs:
>
> Could you send me your tests so that I add them to the proper regression
> test? I've been lazy on one or two object types and obviously that's
> where I have to check some more.
Which tests? The FTS Config test was what I posted before. I haven't
gone to any great effort to set up tests for each command. I've just
been making them up as I go along.
>> What is DROP ASSERTION? It's showing as a valid command for a command
>> trigger, but it's not documented.
>
> It's a Not Implemented Feature for which we have the grammar support to
> be able to fill a standard compliant checkbox, or something like that.
> It could be better for me to remove explicit support for it in the
> command triggers patch?
Well considering there are commands that exist which we don't allow
triggers on, it seems weird to support triggers on commands which
aren't implemented. DROP ASSERTION doesn't appear anywhere else in
the documentation, so I can't think of how supporting a trigger for it
could be useful.
>> I've noticed that ALTER <object> name OWNER TO role doesn't result in
>> any trigger being fired except for tables.
>>
>> ALTER OPERATOR FAMILY .... RENAME TO ... doesn't fire command triggers.
>>
>> ALTER OPERATOR CLASS with RENAME TO or OWNER TO doesn't fire command
>> triggers, but with SET SCHEMA it does.
>
> It seems I've forgotten to add some support here, that happens in
> alter.c and is easy enough to check and complete, thanks for the
> testing.
So would the fix cover many cases at once?
>> I'll hold off on testing any further until a new patch is available.
>
> That should happen soon. Ah, the joys of coding while kids are at home
> thanks to school holidays. I can't count how many times I've been killed
> by a captain and married to a princess while writing that patch, sorry
> about those hiccups here.
Being killed by a captain does make things more difficult, yes.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-26 23:24 ` Thom Brown <thom@linux.com>
2012-02-27 19:31 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-26 23:24 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 26 February 2012 19:49, Thom Brown <thom@linux.com> wrote:
> On 26 February 2012 14:12, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Thanks for your further testing!
>>
>> Thom Brown <thom@linux.com> writes:
>>> Further testing reveals a problem with FTS configurations when using
>>> the example function provided in the docs:
>>
>> Could you send me your tests so that I add them to the proper regression
>> test? I've been lazy on one or two object types and obviously that's
>> where I have to check some more.
>
> Which tests? The FTS Config test was what I posted before. I haven't
> gone to any great effort to set up tests for each command. I've just
> been making them up as I go along.
>
>>> What is DROP ASSERTION? It's showing as a valid command for a command
>>> trigger, but it's not documented.
>>
>> It's a Not Implemented Feature for which we have the grammar support to
>> be able to fill a standard compliant checkbox, or something like that.
>> It could be better for me to remove explicit support for it in the
>> command triggers patch?
>
> Well considering there are commands that exist which we don't allow
> triggers on, it seems weird to support triggers on commands which
> aren't implemented. DROP ASSERTION doesn't appear anywhere else in
> the documentation, so I can't think of how supporting a trigger for it
> could be useful.
>
>>> I've noticed that ALTER <object> name OWNER TO role doesn't result in
>>> any trigger being fired except for tables.
>>>
>>> ALTER OPERATOR FAMILY .... RENAME TO ... doesn't fire command triggers.
>>>
>>> ALTER OPERATOR CLASS with RENAME TO or OWNER TO doesn't fire command
>>> triggers, but with SET SCHEMA it does.
>>
>> It seems I've forgotten to add some support here, that happens in
>> alter.c and is easy enough to check and complete, thanks for the
>> testing.
>
> So would the fix cover many cases at once?
>
>>> I'll hold off on testing any further until a new patch is available.
>>
>> That should happen soon. Ah, the joys of coding while kids are at home
>> thanks to school holidays. I can't count how many times I've been killed
>> by a captain and married to a princess while writing that patch, sorry
>> about those hiccups here.
>
> Being killed by a captain does make things more difficult, yes.
I've got a question regarding the function signatures required for
command triggers, and apologies if it's already been discussed to
death (I didn't see all the original conversations around this).
These differ from regular trigger functions which don't require any
arguments, and instead use special variables. Why aren't we doing the
same for command triggers? So instead of having the parameters
tg_when, cmd_tag, objectid, schemaname and objectname, using pl/pgsql
as an example, we'd have the variables TG_WHEN (already exists), TG_OP
(already exists and equivalent to cmd_tag), TG_RELID (already exists,
although maybe not directly equivalent), TG_REL_SCHEMA (doesn't exist
but would replace schemaname) and TG_RELNAME (this is actually
deprecated but could be re-used for this purpose).
Advantages of implementing it like this is that there's consistency in
the trigger system, it's easier as no function parameters required,
and any future options you may wish to add won't break functions from
previous versions, meaning more room for adding stuff later on.
Disadvantages are that there's more maintenance overhead for
supporting multiple languages using special variables.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-27 19:31 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 20:53 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-27 19:31 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> I've got a question regarding the function signatures required for
> command triggers, and apologies if it's already been discussed to
> death (I didn't see all the original conversations around this).
> These differ from regular trigger functions which don't require any
> arguments, and instead use special variables. Why aren't we doing the
> same for command triggers? So instead of having the parameters
Basically so that we don't have to special code support for each and
every language out there.
> Disadvantages are that there's more maintenance overhead for
> supporting multiple languages using special variables.
Lots of, so I've been told, enough of it for not taking this choice
seriously. I'll admit I didn't personally looked at what it would
entail implementation wise.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:31 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-27 20:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-27 21:22 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-04 18:08 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Tom Lane @ 2012-02-27 20:53 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>; +Cc: Thom Brown <thom@linux.com>; pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Thom Brown <thom@linux.com> writes:
>> I've got a question regarding the function signatures required for
>> command triggers, and apologies if it's already been discussed to
>> death (I didn't see all the original conversations around this).
>> These differ from regular trigger functions which don't require any
>> arguments, and instead use special variables. Why aren't we doing the
>> same for command triggers? So instead of having the parameters
> Basically so that we don't have to special code support for each and
> every language out there.
FWIW, I agree with Thom on this. If we do it as you suggest, I
confidently predict that it will be less than a year before we seriously
regret it. Given all the discussion around this, it's borderline insane
to believe that the set of parameters to be passed to command triggers
is nailed down and won't need to change in the future.
As for special coding of support, it hardly seems onerous when every
language that has triggers at all has got some provision for the
existing trigger parameters. A bit of copying and pasting should get
the job done.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:31 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 20:53 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-02-27 21:22 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-27 21:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>; Thom Brown <thom@linux.com>; pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command triggers
> is nailed down and won't need to change in the future.
I agree with the analysis…
> As for special coding of support, it hardly seems onerous when every
> language that has triggers at all has got some provision for the
> existing trigger parameters. A bit of copying and pasting should get
> the job done.
But had been (too easily) convinced not to take that route. You changed
my mind already, I'll see about changing the code too tomorrow (a cold
is having me out of steam for tonight).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:31 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 20:53 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-03-04 18:08 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-04 18:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Dimitri Fontaine <dimitri@2ndQuadrant.fr>; Thom Brown <thom@linux.com>; pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> FWIW, I agree with Thom on this. If we do it as you suggest, I
> confidently predict that it will be less than a year before we seriously
> regret it. Given all the discussion around this, it's borderline insane
> to believe that the set of parameters to be passed to command triggers
> is nailed down and won't need to change in the future.
>
> As for special coding of support, it hardly seems onerous when every
> language that has triggers at all has got some provision for the
> existing trigger parameters. A bit of copying and pasting should get
> the job done.
So, for that to happen I need to add a new macro and use it in most call
sites of CALLED_AS_TRIGGER(fcinfo). That includes the setup switch in
src/pl/plpgsql/src/pl_comp.c doCompile() and plpgsql_call_handler() for
starters.
Let's call the macro CALLED_AS_COMMAND_TRIGGER(fcinfo), and I would
extend CommandContextData to be a Node of type CommandTriggerData, that
needs to be added to the NodeTag enum as T_CommandTriggerData.
With that in place I can stuff the data into the function's call context
(via InitFunctionCallInfoData) then edit the call handlers of included
procedure languages until they are able to init their language variables
with the info.
Then, do we want the command trigger functions to return type trigger or
another specific type? I guess we want to forbid registering any
function as a command trigger?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-27 19:19 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-27 19:19 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> SELECT * INTO badname FROM goodname;
Again, see Andres' patch about that.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-27 19:19 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-02-27 19:19 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> SELECT 1
>
> This doesn't even get picked up by ANY COMMAND.
You won't believe it: CTAS is not implemented as a DDL. Andres did
some work about that and sent a patch that received positive reviews by
both Tom and Robert, once that's in I can easily add support for the
command.
Thanks Andres :)
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-02-27 19:30 ` Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-02-27 19:30 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On 27 February 2012 19:19, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Thom Brown <thom@linux.com> writes:
>> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
>> SELECT 1
>>
>> This doesn't even get picked up by ANY COMMAND.
>
> You won't believe it: CTAS is not implemented as a DDL. Andres did
> some work about that and sent a patch that received positive reviews by
> both Tom and Robert, once that's in I can easily add support for the
> command.
>
> Thanks Andres :)
I don't see it anywhere in the commitfest. Has it been properly submitted?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-02-27 19:37 ` Andres Freund <andres@anarazel.de>
2012-02-27 23:32 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-02-27 19:37 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Monday, February 27, 2012 08:30:31 PM Thom Brown wrote:
> On 27 February 2012 19:19, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> > Thom Brown <thom@linux.com> writes:
> >> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> >> SELECT 1
> >>
> >> This doesn't even get picked up by ANY COMMAND.
> >
> > You won't believe it: CTAS is not implemented as a DDL. Andres did
> > some work about that and sent a patch that received positive reviews by
> > both Tom and Robert, once that's in I can easily add support for the
> > command.
I actually don't think anybody actually reviewed the patch so far. Tom and I
discussed the implementation strategy beforehand a bit though.
> > Thanks Andres :)
Youre welcome. Thanks for your awesome work that actually made it necessary ;)
> I don't see it anywhere in the commitfest. Has it been properly submitted?
I actually always viewed it as a part of the Dim's patch which is why I didn't
submit it as a separate patch. Maybe that was a mistake...
http://archives.postgresql.org/message-
id/201112112346.07611.andres@anarazel.de contains the latest revision.
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-02-27 23:32 ` Andres Freund <andres@anarazel.de>
2012-02-28 00:21 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-02-27 23:32 UTC (permalink / raw)
To: pgsql-hackers@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
On Monday, February 27, 2012 08:37:24 PM Andres Freund wrote:
> On Monday, February 27, 2012 08:30:31 PM Thom Brown wrote:
> > On 27 February 2012 19:19, Dimitri Fontaine <dimitri@2ndquadrant.fr>
wrote:
> > > Thom Brown <thom@linux.com> writes:
> > >> test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a, ''::text b;
> > >> SELECT 1
> > >>
> > >> This doesn't even get picked up by ANY COMMAND.
> > >
> > > You won't believe it: CTAS is not implemented as a DDL. Andres did
> > > some work about that and sent a patch that received positive reviews by
> > > both Tom and Robert, once that's in I can easily add support for the
> > > command.
>
> I actually don't think anybody actually reviewed the patch so far. Tom and
> I discussed the implementation strategy beforehand a bit though.
>
> > > Thanks Andres :)
>
> Youre welcome. Thanks for your awesome work that actually made it necessary
> ;)
>
> > I don't see it anywhere in the commitfest. Has it been properly
> > submitted?
>
> I actually always viewed it as a part of the Dim's patch which is why I
> didn't submit it as a separate patch. Maybe that was a mistake...
>
> http://archives.postgresql.org/message-
> id/201112112346.07611.andres@anarazel.de contains the latest revision.
>
I refreshed the patch so it works again on current HEAD. Basically some
trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The latter doesn't
seem necessary to me after the changes, so I simply ditched it. Am I missing
something?
I noticed no new things I dislike about the patch besides what I voiced last
time round:
> I attached the - from my side - final version of the patch. I dislike two
> things about it:
> * code duplication due to error handling. Before making the error message
> for various illegal SELECT INTOs the patch actually shrank the code size...
> If anybody has a good idea to avoid duplicating that loop around SelectStmt-
ops I would be happy.
> * new executor flags to define whether oids should be returned
It would be great if somebody could take a look.
Andres
Attachments:
0001-Transform-CREATE-TABLE-AS-SELECT-INTO-into-a-utility.patch (text/x-patch, 76.9K) download
From 10a3e5c26c4196cdb8ce4ba588c19872d2f1b246 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Tue, 28 Feb 2012 00:19:50 +0100
Subject: [PATCH] Transform CREATE TABLE AS/SELECT INTO into a utility
statement
This basically includes a revert of d8fb1f9adbddd1eef123d66a89a9fc0ecd96f60b
which doesn't seem to be necessary anymore now CTAS is a proper utility
statement in any incarnation.
---
src/backend/commands/copy.c | 20 +-
src/backend/commands/prepare.c | 69 +----
src/backend/commands/tablecmds.c | 335 +++++++++++++++++++++
src/backend/commands/view.c | 20 +-
src/backend/executor/execMain.c | 441 ++--------------------------
src/backend/executor/execUtils.c | 2 -
src/backend/executor/functions.c | 4 +-
src/backend/executor/spi.c | 10 +-
src/backend/nodes/copyfuncs.c | 18 +-
src/backend/nodes/equalfuncs.c | 16 +-
src/backend/nodes/outfuncs.c | 4 +-
src/backend/nodes/readfuncs.c | 1 -
src/backend/optimizer/plan/planner.c | 1 -
src/backend/optimizer/plan/subselect.c | 1 -
src/backend/optimizer/prep/prepjointree.c | 6 +-
src/backend/optimizer/util/clauses.c | 4 +-
src/backend/parser/analyze.c | 113 +++++---
src/backend/parser/gram.y | 28 ++-
src/backend/parser/parse_clause.c | 21 +-
src/backend/parser/parse_cte.c | 21 +-
src/backend/parser/parse_expr.c | 21 +-
src/backend/parser/parser.c | 38 +++
src/backend/rewrite/rewriteDefine.c | 3 +-
src/backend/tcop/pquery.c | 13 +-
src/backend/tcop/utility.c | 46 ++--
src/include/access/htup.h | 2 +-
src/include/commands/prepare.h | 3 +
src/include/commands/tablecmds.h | 4 +
src/include/executor/executor.h | 5 +
src/include/nodes/execnodes.h | 9 +-
src/include/nodes/nodes.h | 1 +
src/include/nodes/parsenodes.h | 20 +-
src/include/nodes/plannodes.h | 2 -
src/pl/plpgsql/src/pl_exec.c | 27 +--
src/test/regress/expected/select_into.out | 19 ++
src/test/regress/expected/transactions.out | 2 +-
src/test/regress/sql/select_into.sql | 15 +
37 files changed, 720 insertions(+), 645 deletions(-)
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 110480f..a3c5b4b 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -1190,6 +1190,20 @@ BeginCopy(bool is_from,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY (SELECT) WITH OIDS is not supported")));
+
+ /* Query mustn't use INTO, either */
+ if(IsA(raw_query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)raw_query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("COPY (SELECT INTO) is not supported")));
+ }
+
/*
* Run parse analysis and rewrite. Note this also acquires sufficient
* locks on the source table(s).
@@ -1211,12 +1225,6 @@ BeginCopy(bool is_from,
Assert(query->commandType == CMD_SELECT);
Assert(query->utilityStmt == NULL);
- /* Query mustn't use INTO, either */
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("COPY (SELECT INTO) is not supported")));
-
/* plan the query */
plan = planner(query, 0, NULL);
diff --git a/src/backend/commands/prepare.c b/src/backend/commands/prepare.c
index 4883abe..86e8cf9 100644
--- a/src/backend/commands/prepare.c
+++ b/src/backend/commands/prepare.c
@@ -43,8 +43,6 @@
static HTAB *prepared_queries = NULL;
static void InitQueryHashTable(void);
-static ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
- const char *queryString, EState *estate);
static Datum build_regtype_array(Oid *param_types, int num_params);
/*
@@ -177,6 +175,9 @@ PrepareQuery(PrepareStmt *stmt, const char *queryString)
* EXECUTE, which we might need for error reporting while processing the
* parameter expressions. The query_string that we copy from the plan
* source is that of the original PREPARE.
+ *
+ * If you add additional things here you should check whether
+ * CreateTableAs also needs them.
*/
void
ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
@@ -222,51 +223,9 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
query_string = MemoryContextStrdup(PortalGetHeapMemory(portal),
entry->plansource->query_string);
- /*
- * For CREATE TABLE / AS EXECUTE, we must make a copy of the stored query
- * so that we can modify its destination (yech, but this has always been
- * ugly). For regular EXECUTE we can just use the cached query, since the
- * executor is read-only.
- */
- if (stmt->into)
- {
- MemoryContext oldContext;
- PlannedStmt *pstmt;
-
- /* Replan if needed, and increment plan refcount transiently */
- cplan = GetCachedPlan(entry->plansource, paramLI, true);
-
- /* Copy plan into portal's context, and modify */
- oldContext = MemoryContextSwitchTo(PortalGetHeapMemory(portal));
-
- plan_list = copyObject(cplan->stmt_list);
-
- if (list_length(plan_list) != 1)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt = (PlannedStmt *) linitial(plan_list);
- if (!IsA(pstmt, PlannedStmt) ||
- pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
- pstmt->intoClause = copyObject(stmt->into);
-
- MemoryContextSwitchTo(oldContext);
-
- /* We no longer need the cached plan refcount ... */
- ReleaseCachedPlan(cplan, true);
- /* ... and we don't want the portal to depend on it, either */
- cplan = NULL;
- }
- else
- {
- /* Replan if needed, and increment plan refcount for portal */
- cplan = GetCachedPlan(entry->plansource, paramLI, false);
- plan_list = cplan->stmt_list;
- }
+ /* Replan if needed, and increment plan refcount for portal */
+ cplan = GetCachedPlan(entry->plansource, paramLI, false);
+ plan_list = cplan->stmt_list;
PortalDefineQuery(portal,
NULL,
@@ -302,7 +261,7 @@ ExecuteQuery(ExecuteStmt *stmt, const char *queryString,
* CreateQueryDesc(), which allows the executor to make use of the parameters
* during query execution.
*/
-static ParamListInfo
+ParamListInfo
EvaluateParams(PreparedStatement *pstmt, List *params,
const char *queryString, EState *estate)
{
@@ -666,20 +625,6 @@ ExplainExecuteQuery(ExecuteStmt *execstmt, ExplainState *es,
if (IsA(pstmt, PlannedStmt))
{
- if (execstmt->into)
- {
- if (pstmt->commandType != CMD_SELECT ||
- pstmt->utilityStmt != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_WRONG_OBJECT_TYPE),
- errmsg("prepared statement is not a SELECT")));
-
- /* Copy the stmt so we can modify it */
- pstmt = copyObject(pstmt);
-
- pstmt->intoClause = execstmt->into;
- }
-
ExplainOnePlan(pstmt, es, query_string, paramLI);
}
else
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index cd4490a..9a67cf5 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -44,6 +44,7 @@
#include "commands/cluster.h"
#include "commands/comment.h"
#include "commands/defrem.h"
+#include "commands/prepare.h"
#include "commands/sequence.h"
#include "commands/tablecmds.h"
#include "commands/tablespace.h"
@@ -68,6 +69,7 @@
#include "parser/parser.h"
#include "rewrite/rewriteDefine.h"
#include "rewrite/rewriteHandler.h"
+#include "tcop/tcopprot.h"
#include "storage/bufmgr.h"
#include "storage/lmgr.h"
#include "storage/lock.h"
@@ -195,6 +197,18 @@ struct dropmsgstrings
const char *drophint_msg;
};
+/*
+ * Support structure for CTAS
+ */
+typedef struct
+{
+ DestReceiver pub; /* publicly-known function pointers */
+ EState *estate; /* EState we are working with */
+ Relation rel; /* Relation to write to */
+ int hi_options; /* heap_insert performance options */
+ BulkInsertState bistate; /* bulk insert state */
+} DR_intorel;
+
static const struct dropmsgstrings dropmsgstringarray[] = {
{RELKIND_RELATION,
ERRCODE_UNDEFINED_TABLE,
@@ -671,6 +685,235 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId)
return relationId;
}
+void
+CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest){
+ IntoClause *into = stmt->into;
+ Query *query;
+ List *rewritten;
+ PlannedStmt *plan;
+ QueryDesc *queryDesc;
+ Relation intoRelationDesc;
+ CreateStmt *create;
+ int natt;
+ Oid intoRelationId;
+ ListCell *lc;
+ int eflags = 0;
+ EState *param_estate = NULL;
+ CachedPlan *cplan = NULL;
+
+ Assert(IsA(stmt->query, Query));
+ query = (Query*)stmt->query;
+
+ /*
+ * Construct plans for the supported
+ */
+ if(query->commandType == CMD_SELECT){
+ rewritten = QueryRewrite((Query *) copyObject(stmt->query));
+
+ if(!rewritten)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to nothing");
+
+ if(list_length(rewritten) != 1)
+ elog(ERROR, "CREATE TABLE AS/SELECT INTO query rewrote to more than one query");
+
+ plan = pg_plan_query(lfirst(list_head(rewritten)), 0, params);
+ }
+ else if(query->commandType == CMD_UTILITY &&
+ IsA(query->utilityStmt, ExecuteStmt)){
+ /*
+ * We cannot easily share more infrastructure with prepare.c's
+ * ExecuteQuery because teaching it to return a started
+ * executor would amount to about the same amount of
+ * duplication as doing it here.
+ *
+ */
+ ExecuteStmt *stmt;
+ PreparedStatement *entry;
+ List *plan_list;
+ ParamListInfo paramLI = NULL;
+
+ Assert(IsA(query->utilityStmt, ExecuteStmt));
+ stmt = (ExecuteStmt*)(query->utilityStmt);
+
+ entry = FetchPreparedStatement(stmt->name, true);
+
+ /* Shouldn't find a non-fixed-result cached plan */
+ if (!entry->plansource->fixed_result)
+ elog(ERROR, "EXECUTE does not support variable-result cached plans");
+
+ /* Evaluate parameters, if any */
+ if (entry->plansource->num_params > 0)
+ {
+ param_estate = CreateExecutorState();
+ param_estate->es_param_list_info = params;
+ paramLI = EvaluateParams(entry, stmt->params,
+ queryString, param_estate);
+
+ }
+
+ cplan = GetCachedPlan(entry->plansource, paramLI, true);
+ plan_list = cplan->stmt_list;
+
+ if (list_length(plan_list) != 1)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ plan = (PlannedStmt *) linitial(plan_list);
+ if (!IsA(plan, PlannedStmt) ||
+ plan->commandType != CMD_SELECT ||
+ plan->utilityStmt != NULL)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("prepared statement is not a SELECT")));
+
+ queryString = pstrdup(entry->plansource->query_string);
+ }
+ else{
+ elog(ERROR, "unsupported command for CREATE TABLE AS");
+ abort();//silence compiler
+ }
+
+
+ /*
+ * Use a snapshot with an updated command ID to ensure this query sees
+ * results of any previously executed queries.
+ */
+ PushCopiedSnapshot(GetActiveSnapshot());
+ UpdateActiveSnapshotCommandId();
+
+ queryDesc = CreateQueryDesc(plan, queryString,
+ GetActiveSnapshot(), InvalidSnapshot,
+ CreateDestReceiver(DestIntoRel), params,
+ false);
+
+ /*
+ * We need to tell the executor whether it has to produce oids or
+ * not because it doesn't have enough information to do so itself
+ * as were not telling it that its inserting into a table (because
+ * that would be too complicated for now)
+ */
+ if(interpretOidsOption(into->options))
+ eflags |= EXEC_FLAG_FORCE_OIDS_ON;
+ else
+ eflags |= EXEC_FLAG_FORCE_OIDS_OFF;
+
+ /*
+ * call ExecutorStart to prepare the plan for execution. Only
+ * after this we have enough information to actually create a
+ * target relation
+ */
+ ExecutorStart(queryDesc, eflags);
+
+ /*
+ * create the target relation
+ */
+ create = makeNode(CreateStmt);
+ create->relation = into->rel;
+ create->options = into->options;
+ create->oncommit = into->onCommit;
+ create->tablespacename = into->tableSpaceName;
+
+ /*
+ * If a column name list was specified in CREATE TABLE AS,
+ * override the column names derived from the query. (Too few
+ * column names are OK, too many are not.)
+ */
+ if (list_length(into->colNames) > queryDesc->tupDesc->natts)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("CREATE TABLE AS specifies too many column names")));
+ lc = list_head(into->colNames);
+ for(natt = 0; natt < queryDesc->tupDesc->natts; natt++){
+ ColumnDef *col = makeNode(ColumnDef);
+ TypeName *type = makeNode(TypeName);
+
+ Form_pg_attribute attribute = queryDesc->tupDesc->attrs[natt];
+
+ if(!lc)
+ col->colname = NameStr(attribute->attname);
+ else{
+ col->colname = strVal(lfirst(lc));
+ lc = lnext(lc);
+ }
+
+ col->collOid = attribute->attcollation;
+
+ type->typeOid = attribute->atttypid;
+ type->typemod = attribute->atttypmod;
+ col->typeName= type;
+
+ /*
+ * We check the column type here because collOid=InvalidOid
+ * denotes an invalid oid for a collatable type in
+ * queryDesc->tupDesc but GetColumnDefCollation - which will
+ * be called by DefineRelation - defers the default collation
+ * out of that...
+ * XXX: A better solution would be welcome.
+ */
+ CheckAttributeType(col->colname, col->typeName->typeOid, col->collOid,
+ NULL, false);
+ create->tableElts = lappend(create->tableElts, col);
+ }
+
+ /*
+ * Actually create the target table
+ */
+ intoRelationId = DefineRelation(create, RELKIND_RELATION, InvalidOid);
+ intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
+
+
+ if(!into->skipData){
+ DR_intorel *myState = (DR_intorel *) queryDesc->dest;
+ /* setup the target of the DestIntoRel receiver */
+ myState->estate = queryDesc->estate;
+ myState->rel = intoRelationDesc;
+
+ /* run the plan */
+ ExecutorRun(queryDesc, ForwardScanDirection, 0L);
+
+ }
+
+ /*
+ * Check INSERT permission on the constructed table.
+ *
+ * XXX: It would arguable make sense to do this check only if
+ * into->skipData is true.
+ */
+ {
+ RangeTblEntry *rte = makeNode(RangeTblEntry);
+ rte->rtekind = RTE_RELATION;
+ rte->relid = intoRelationId;
+ rte->relkind = RELKIND_RELATION;
+ rte->requiredPerms = ACL_INSERT;
+
+ for (natt = 1; natt <= intoRelationDesc->rd_att->natts; natt++)
+ rte->modifiedCols = bms_add_member(rte->modifiedCols,
+ natt - FirstLowInvalidHeapAttributeNumber);
+
+ ExecCheckRTPerms(list_make1(rte), true);
+ }
+
+ /* run cleanup too */
+ ExecutorFinish(queryDesc);
+ ExecutorEnd(queryDesc);
+
+ /* close rel, but keep lock until commit */
+ heap_close(intoRelationDesc, NoLock);
+
+ FreeQueryDesc(queryDesc);
+
+ if(cplan){
+ ReleaseCachedPlan(cplan, true);
+
+ if (param_estate)
+ FreeExecutorState(param_estate);
+ }
+
+ PopActiveSnapshot();
+}
+
/*
* Emit the right error or warning message for a "DROP" command issued on a
* non-existent relation
@@ -10238,3 +10481,95 @@ RangeVarCallbackForAlterRelation(const RangeVar *rv, Oid relid, Oid oldrelid,
ReleaseSysCache(tuple);
}
+
+/*
+ * Support for SELECT INTO (aka CREATE TABLE AS)
+ *
+ * We implement SELECT INTO by diverting SELECT's normal output with
+ * a specialized DestReceiver type.
+ */
+
+/*
+ * intorel_startup --- executor startup
+ */
+static void
+intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ myState->bistate = GetBulkInsertState();
+ myState->hi_options = HEAP_INSERT_SKIP_FSM;
+ if (!XLogIsNeeded())
+ myState->hi_options |= HEAP_INSERT_SKIP_WAL;
+
+}
+
+/*
+ * intorel_receive --- receive one tuple
+ */
+static void
+intorel_receive(TupleTableSlot *slot, DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+ HeapTuple tuple;
+
+ /*
+ * get the heap tuple out of the tuple table slot, making sure we have a
+ * writable copy
+ */
+ tuple = ExecMaterializeSlot(slot);
+
+ /*
+ * force assignment of new OID (see comments in ExecInsert)
+ */
+ if (myState->rel->rd_rel->relhasoids)
+ HeapTupleSetOid(tuple, InvalidOid);
+
+ heap_insert(myState->rel,
+ tuple,
+ myState->estate->es_output_cid,
+ myState->hi_options,
+ myState->bistate);
+
+ /* We know this is a newly created relation, so there are no indexes */
+}
+
+/*
+ * intorel_shutdown --- executor end
+ */
+static void
+intorel_shutdown(DestReceiver *self)
+{
+ DR_intorel *myState = (DR_intorel *) self;
+
+ FreeBulkInsertState(myState->bistate);
+ if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
+ heap_sync(myState->rel);
+}
+
+/*
+ * intorel_destroy --- release DestReceiver object
+ */
+static void
+intorel_destroy(DestReceiver *self)
+{
+ pfree(self);
+}
+
+/*
+ * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
+ *
+ */
+DestReceiver *
+CreateIntoRelDestReceiver(void)
+{
+ DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
+
+ self->pub.receiveSlot = intorel_receive;
+ self->pub.rStartup = intorel_startup;
+ self->pub.rShutdown = intorel_shutdown;
+ self->pub.rDestroy = intorel_destroy;
+ self->pub.mydest = DestIntoRel;
+ /* private fields will be set on startup */
+
+ return (DestReceiver *) self;
+}
diff --git a/src/backend/commands/view.c b/src/backend/commands/view.c
index 99fb7db..93e523a 100644
--- a/src/backend/commands/view.c
+++ b/src/backend/commands/view.c
@@ -428,6 +428,22 @@ DefineView(ViewStmt *stmt, const char *queryString)
RangeVar *view;
/*
+ * We check for SELECT INTO before parse analysis because that
+ * would complain about the SELECT INTO without specific enough detail.
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("views must not contain SELECT INTO")));
+ }
+
+ /*
* Run parse analysis to convert the raw parse tree to a Query. Note this
* also acquires sufficient locks on the source table(s).
*
@@ -449,10 +465,6 @@ DefineView(ViewStmt *stmt, const char *queryString)
* DefineQueryRewrite(), but that function will complain about a bogus ON
* SELECT rule, and we'd rather the message complain about a view.
*/
- if (viewParse->intoClause != NULL)
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("views must not contain SELECT INTO")));
if (viewParse->hasModifyingCTE)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 36dcc8e..1979325 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -90,12 +90,6 @@ static char *ExecBuildSlotValueDescription(TupleTableSlot *slot,
int maxfieldlen);
static void EvalPlanQualStart(EPQState *epqstate, EState *parentestate,
Plan *planTree);
-static void OpenIntoRel(QueryDesc *queryDesc);
-static void CloseIntoRel(QueryDesc *queryDesc);
-static void intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo);
-static void intorel_receive(TupleTableSlot *slot, DestReceiver *self);
-static void intorel_shutdown(DestReceiver *self);
-static void intorel_destroy(DestReceiver *self);
/* end of local decls */
@@ -174,11 +168,10 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
case CMD_SELECT:
/*
- * SELECT INTO, SELECT FOR UPDATE/SHARE and modifying CTEs need to
+ * SELECT FOR UPDATE/SHARE and modifying CTEs need to
* mark tuples
*/
- if (queryDesc->plannedstmt->intoClause != NULL ||
- queryDesc->plannedstmt->rowMarks != NIL ||
+ if (queryDesc->plannedstmt->rowMarks != NIL ||
queryDesc->plannedstmt->hasModifyingCTE)
estate->es_output_cid = GetCurrentCommandId(true);
@@ -212,6 +205,13 @@ standard_ExecutorStart(QueryDesc *queryDesc, int eflags)
estate->es_top_eflags = eflags;
estate->es_instrument = queryDesc->instrument_options;
+ if(eflags & EXEC_FLAG_FORCE_OIDS_ON)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_ON;
+ else if(eflags & EXEC_FLAG_FORCE_OIDS_OFF)
+ estate->es_force_oids = ESTATE_FORCE_OIDS_OFF;
+ else
+ estate->es_force_oids = ESTATE_FORCE_OIDS_DEFAULT;
+
/*
* Initialize the plan state tree
*/
@@ -310,13 +310,6 @@ standard_ExecutorRun(QueryDesc *queryDesc,
(*dest->rStartup) (dest, operation, queryDesc->tupDesc);
/*
- * if it's CREATE TABLE AS ... WITH NO DATA, skip plan execution
- */
- if (estate->es_select_into &&
- queryDesc->plannedstmt->intoClause->skipData)
- direction = NoMovementScanDirection;
-
- /*
* run plan
*/
if (!ScanDirectionIsNoMovement(direction))
@@ -451,12 +444,6 @@ standard_ExecutorEnd(QueryDesc *queryDesc)
ExecEndPlan(queryDesc->planstate, estate);
- /*
- * Close the SELECT INTO relation if any
- */
- if (estate->es_select_into)
- CloseIntoRel(queryDesc);
-
/* do away with our snapshots */
UnregisterSnapshot(estate->es_snapshot);
UnregisterSnapshot(estate->es_crosscheck_snapshot);
@@ -706,15 +693,6 @@ ExecCheckXactReadOnly(PlannedStmt *plannedstmt)
{
ListCell *l;
- /*
- * CREATE TABLE AS or SELECT INTO?
- *
- * XXX should we allow this if the destination is temp? Considering that
- * it would still require catalog changes, probably not.
- */
- if (plannedstmt->intoClause != NULL)
- PreventCommandIfReadOnly(CreateCommandTag((Node *) plannedstmt));
-
/* Fail if write permissions are requested on any non-temp table */
foreach(l, plannedstmt->rtable)
{
@@ -864,18 +842,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
}
/*
- * Detect whether we're doing SELECT INTO. If so, set the es_into_oids
- * flag appropriately so that the plan tree will be initialized with the
- * correct tuple descriptors. (Other SELECT INTO stuff comes later.)
- */
- estate->es_select_into = false;
- if (operation == CMD_SELECT && plannedstmt->intoClause != NULL)
- {
- estate->es_select_into = true;
- estate->es_into_oids = interpretOidsOption(plannedstmt->intoClause->options);
- }
-
- /*
* Initialize the executor's tuple table to empty.
*/
estate->es_tupleTable = NIL;
@@ -926,9 +892,7 @@ InitPlan(QueryDesc *queryDesc, int eflags)
planstate = ExecInitNode(plan, estate, eflags);
/*
- * Get the tuple descriptor describing the type of tuples to return. (this
- * is especially important if we are creating a relation with "SELECT
- * INTO")
+ * Get the tuple descriptor describing the type of tuples to return.
*/
tupType = ExecGetResultType(planstate);
@@ -968,16 +932,6 @@ InitPlan(QueryDesc *queryDesc, int eflags)
queryDesc->tupDesc = tupType;
queryDesc->planstate = planstate;
-
- /*
- * If doing SELECT INTO, initialize the "into" relation. We must wait
- * till now so we have the "clean" result tuple type to create the new
- * table from.
- *
- * If EXPLAIN, skip creating the "into" relation.
- */
- if (estate->es_select_into && !(eflags & EXEC_FLAG_EXPLAIN_ONLY))
- OpenIntoRel(queryDesc);
}
/*
@@ -1230,7 +1184,7 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
/*
* ExecContextForcesOids
*
- * This is pretty grotty: when doing INSERT, UPDATE, or SELECT INTO,
+ * This is pretty grotty: when doing INSERT or UPDATE
* we need to ensure that result tuples have space for an OID iff they are
* going to be stored into a relation that has OIDs. In other contexts
* we are free to choose whether to leave space for OIDs in result tuples
@@ -1255,15 +1209,25 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
* the ModifyTable node, so ModifyTable has to set es_result_relation_info
* while initializing each subplan.
*
- * SELECT INTO is even uglier, because we don't have the INTO relation's
- * descriptor available when this code runs; we have to look aside at a
- * flag set by InitPlan().
+ * SELECT INTO is even uglier, because we don't have the INTO
+ * relation's descriptor available - because its only defined after
+ * the query started - when this code runs; we have to look aside at
+ * flags which is passed to ExecutorStart via eflags.
*/
bool
ExecContextForcesOids(PlanState *planstate, bool *hasoids)
{
ResultRelInfo *ri = planstate->state->es_result_relation_info;
+ if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_ON){
+ *hasoids = true;
+ return true;
+ }
+ else if(planstate->state->es_force_oids == ESTATE_FORCE_OIDS_OFF){
+ *hasoids = false;
+ return true;
+ }
+
if (ri != NULL)
{
Relation rel = ri->ri_RelationDesc;
@@ -1275,12 +1239,6 @@ ExecContextForcesOids(PlanState *planstate, bool *hasoids)
}
}
- if (planstate->state->es_select_into)
- {
- *hasoids = planstate->state->es_into_oids;
- return true;
- }
-
return false;
}
@@ -2290,8 +2248,7 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
estate->es_rowMarks = parentestate->es_rowMarks;
estate->es_top_eflags = parentestate->es_top_eflags;
estate->es_instrument = parentestate->es_instrument;
- estate->es_select_into = parentestate->es_select_into;
- estate->es_into_oids = parentestate->es_into_oids;
+
/* es_auxmodifytables must NOT be copied */
/*
@@ -2423,351 +2380,3 @@ EvalPlanQualEnd(EPQState *epqstate)
epqstate->planstate = NULL;
epqstate->origslot = NULL;
}
-
-
-/*
- * Support for SELECT INTO (a/k/a CREATE TABLE AS)
- *
- * We implement SELECT INTO by diverting SELECT's normal output with
- * a specialized DestReceiver type.
- */
-
-typedef struct
-{
- DestReceiver pub; /* publicly-known function pointers */
- EState *estate; /* EState we are working with */
- DestReceiver *origdest; /* QueryDesc's original receiver */
- Relation rel; /* Relation to write to */
- int hi_options; /* heap_insert performance options */
- BulkInsertState bistate; /* bulk insert state */
-} DR_intorel;
-
-/*
- * OpenIntoRel --- actually create the SELECT INTO target relation
- *
- * This also replaces QueryDesc->dest with the special DestReceiver for
- * SELECT INTO. We assume that the correct result tuple type has already
- * been placed in queryDesc->tupDesc.
- */
-static void
-OpenIntoRel(QueryDesc *queryDesc)
-{
- IntoClause *into = queryDesc->plannedstmt->intoClause;
- EState *estate = queryDesc->estate;
- TupleDesc intoTupDesc = queryDesc->tupDesc;
- Relation intoRelationDesc;
- char *intoName;
- Oid namespaceId;
- Oid tablespaceId;
- Datum reloptions;
- Oid intoRelationId;
- DR_intorel *myState;
- RangeTblEntry *rte;
- AttrNumber attnum;
- static char *validnsps[] = HEAP_RELOPT_NAMESPACES;
-
- Assert(into);
-
- /*
- * XXX This code needs to be kept in sync with DefineRelation(). Maybe we
- * should try to use that function instead.
- */
-
- /*
- * Check consistency of arguments
- */
- if (into->onCommit != ONCOMMIT_NOOP
- && into->rel->relpersistence != RELPERSISTENCE_TEMP)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
- errmsg("ON COMMIT can only be used on temporary tables")));
-
- {
- AclResult aclresult;
- int i;
-
- for (i = 0; i < intoTupDesc->natts; i++)
- {
- Oid atttypid = intoTupDesc->attrs[i]->atttypid;
-
- aclresult = pg_type_aclcheck(atttypid, GetUserId(), ACL_USAGE);
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TYPE,
- format_type_be(atttypid));
- }
- }
-
- /*
- * If a column name list was specified in CREATE TABLE AS, override the
- * column names derived from the query. (Too few column names are OK, too
- * many are not.) It would probably be all right to scribble directly on
- * the query's result tupdesc, but let's be safe and make a copy.
- */
- if (into->colNames)
- {
- ListCell *lc;
-
- intoTupDesc = CreateTupleDescCopy(intoTupDesc);
- attnum = 1;
- foreach(lc, into->colNames)
- {
- char *colname = strVal(lfirst(lc));
-
- if (attnum > intoTupDesc->natts)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("CREATE TABLE AS specifies too many column names")));
- namestrcpy(&(intoTupDesc->attrs[attnum - 1]->attname), colname);
- attnum++;
- }
- }
-
- /*
- * Find namespace to create in, check its permissions, lock it against
- * concurrent drop, and mark into->rel as RELPERSISTENCE_TEMP if the
- * selected namespace is temporary.
- */
- intoName = into->rel->relname;
- namespaceId = RangeVarGetAndCheckCreationNamespace(into->rel, NoLock,
- NULL);
-
- /*
- * Security check: disallow creating temp tables from security-restricted
- * code. This is needed because calling code might not expect untrusted
- * tables to appear in pg_temp at the front of its search path.
- */
- if (into->rel->relpersistence == RELPERSISTENCE_TEMP
- && InSecurityRestrictedOperation())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("cannot create temporary table within security-restricted operation")));
-
- /*
- * Select tablespace to use. If not specified, use default tablespace
- * (which may in turn default to database's default).
- */
- if (into->tableSpaceName)
- {
- tablespaceId = get_tablespace_oid(into->tableSpaceName, false);
- }
- else
- {
- tablespaceId = GetDefaultTablespace(into->rel->relpersistence);
- /* note InvalidOid is OK in this case */
- }
-
- /* Check permissions except when using the database's default space */
- if (OidIsValid(tablespaceId) && tablespaceId != MyDatabaseTableSpace)
- {
- AclResult aclresult;
-
- aclresult = pg_tablespace_aclcheck(tablespaceId, GetUserId(),
- ACL_CREATE);
-
- if (aclresult != ACLCHECK_OK)
- aclcheck_error(aclresult, ACL_KIND_TABLESPACE,
- get_tablespace_name(tablespaceId));
- }
-
- /* Parse and validate any reloptions */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- NULL,
- validnsps,
- true,
- false);
- (void) heap_reloptions(RELKIND_RELATION, reloptions, true);
-
- /* Now we can actually create the new relation */
- intoRelationId = heap_create_with_catalog(intoName,
- namespaceId,
- tablespaceId,
- InvalidOid,
- InvalidOid,
- InvalidOid,
- GetUserId(),
- intoTupDesc,
- NIL,
- RELKIND_RELATION,
- into->rel->relpersistence,
- false,
- false,
- true,
- 0,
- into->onCommit,
- reloptions,
- true,
- allowSystemTableMods);
- Assert(intoRelationId != InvalidOid);
-
- /*
- * Advance command counter so that the newly-created relation's catalog
- * tuples will be visible to heap_open.
- */
- CommandCounterIncrement();
-
- /*
- * If necessary, create a TOAST table for the INTO relation. Note that
- * AlterTableCreateToastTable ends with CommandCounterIncrement(), so that
- * the TOAST table will be visible for insertion.
- */
- reloptions = transformRelOptions((Datum) 0,
- into->options,
- "toast",
- validnsps,
- true,
- false);
-
- (void) heap_reloptions(RELKIND_TOASTVALUE, reloptions, true);
-
- AlterTableCreateToastTable(intoRelationId, reloptions);
-
- /*
- * And open the constructed table for writing.
- */
- intoRelationDesc = heap_open(intoRelationId, AccessExclusiveLock);
-
- /*
- * Check INSERT permission on the constructed table.
- */
- rte = makeNode(RangeTblEntry);
- rte->rtekind = RTE_RELATION;
- rte->relid = intoRelationId;
- rte->relkind = RELKIND_RELATION;
- rte->requiredPerms = ACL_INSERT;
-
- for (attnum = 1; attnum <= intoTupDesc->natts; attnum++)
- rte->modifiedCols = bms_add_member(rte->modifiedCols,
- attnum - FirstLowInvalidHeapAttributeNumber);
-
- ExecCheckRTPerms(list_make1(rte), true);
-
- /*
- * Now replace the query's DestReceiver with one for SELECT INTO
- */
- myState = (DR_intorel *) CreateDestReceiver(DestIntoRel);
- Assert(myState->pub.mydest == DestIntoRel);
- myState->estate = estate;
- myState->origdest = queryDesc->dest;
- myState->rel = intoRelationDesc;
-
- queryDesc->dest = (DestReceiver *) myState;
-
- /*
- * We can skip WAL-logging the insertions, unless PITR or streaming
- * replication is in use. We can skip the FSM in any case.
- */
- myState->hi_options = HEAP_INSERT_SKIP_FSM |
- (XLogIsNeeded() ? 0 : HEAP_INSERT_SKIP_WAL);
- myState->bistate = GetBulkInsertState();
-
- /* Not using WAL requires smgr_targblock be initially invalid */
- Assert(RelationGetTargetBlock(intoRelationDesc) == InvalidBlockNumber);
-}
-
-/*
- * CloseIntoRel --- clean up SELECT INTO at ExecutorEnd time
- */
-static void
-CloseIntoRel(QueryDesc *queryDesc)
-{
- DR_intorel *myState = (DR_intorel *) queryDesc->dest;
-
- /*
- * OpenIntoRel might never have gotten called, and we also want to guard
- * against double destruction.
- */
- if (myState && myState->pub.mydest == DestIntoRel)
- {
- FreeBulkInsertState(myState->bistate);
-
- /* If we skipped using WAL, must heap_sync before commit */
- if (myState->hi_options & HEAP_INSERT_SKIP_WAL)
- heap_sync(myState->rel);
-
- /* close rel, but keep lock until commit */
- heap_close(myState->rel, NoLock);
-
- /* restore the receiver belonging to executor's caller */
- queryDesc->dest = myState->origdest;
-
- /* might as well invoke my destructor */
- intorel_destroy((DestReceiver *) myState);
- }
-}
-
-/*
- * CreateIntoRelDestReceiver -- create a suitable DestReceiver object
- */
-DestReceiver *
-CreateIntoRelDestReceiver(void)
-{
- DR_intorel *self = (DR_intorel *) palloc0(sizeof(DR_intorel));
-
- self->pub.receiveSlot = intorel_receive;
- self->pub.rStartup = intorel_startup;
- self->pub.rShutdown = intorel_shutdown;
- self->pub.rDestroy = intorel_destroy;
- self->pub.mydest = DestIntoRel;
-
- /* private fields will be set by OpenIntoRel */
-
- return (DestReceiver *) self;
-}
-
-/*
- * intorel_startup --- executor startup
- */
-static void
-intorel_startup(DestReceiver *self, int operation, TupleDesc typeinfo)
-{
- /* no-op */
-}
-
-/*
- * intorel_receive --- receive one tuple
- */
-static void
-intorel_receive(TupleTableSlot *slot, DestReceiver *self)
-{
- DR_intorel *myState = (DR_intorel *) self;
- HeapTuple tuple;
-
- /*
- * get the heap tuple out of the tuple table slot, making sure we have a
- * writable copy
- */
- tuple = ExecMaterializeSlot(slot);
-
- /*
- * force assignment of new OID (see comments in ExecInsert)
- */
- if (myState->rel->rd_rel->relhasoids)
- HeapTupleSetOid(tuple, InvalidOid);
-
- heap_insert(myState->rel,
- tuple,
- myState->estate->es_output_cid,
- myState->hi_options,
- myState->bistate);
-
- /* We know this is a newly created relation, so there are no indexes */
-}
-
-/*
- * intorel_shutdown --- executor end
- */
-static void
-intorel_shutdown(DestReceiver *self)
-{
- /* no-op */
-}
-
-/*
- * intorel_destroy --- release DestReceiver object
- */
-static void
-intorel_destroy(DestReceiver *self)
-{
- pfree(self);
-}
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index 6db42e7..40cd5ce 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -137,8 +137,6 @@ CreateExecutorState(void)
estate->es_top_eflags = 0;
estate->es_instrument = 0;
- estate->es_select_into = false;
- estate->es_into_oids = false;
estate->es_finished = false;
estate->es_exprcontexts = NIL;
diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index 61f4622..ae8d374 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -535,7 +535,6 @@ init_execution_state(List *queryTree_list,
if (ps->commandType == CMD_SELECT &&
ps->utilityStmt == NULL &&
- ps->intoClause == NULL &&
!ps->hasModifyingCTE)
fcache->lazyEval = lasttages->lazyEval = true;
}
@@ -1493,8 +1492,7 @@ check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,
*/
if (parse &&
parse->commandType == CMD_SELECT &&
- parse->utilityStmt == NULL &&
- parse->intoClause == NULL)
+ parse->utilityStmt == NULL)
{
tlist_ptr = &parse->targetList;
tlist = parse->targetList;
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index 81f284c..ce6abcf 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.c
@@ -1917,7 +1917,11 @@ _SPI_execute_plan(SPIPlanPtr plan, ParamListInfo paramLI,
if (_SPI_current->tuptable)
_SPI_current->processed = _SPI_current->tuptable->alloced -
_SPI_current->tuptable->free;
- res = SPI_OK_UTILITY;
+ if(nodeTag(stmt) == T_CreateTableAsStmt &&
+ ((CreateTableAsStmt*)stmt)->is_select_into)
+ res = SPI_OK_SELINTO;
+ else
+ res = SPI_OK_UTILITY;
}
/*
@@ -2042,9 +2046,7 @@ _SPI_pquery(QueryDesc *queryDesc, bool fire_triggers, long tcount)
{
case CMD_SELECT:
Assert(queryDesc->plannedstmt->utilityStmt == NULL);
- if (queryDesc->plannedstmt->intoClause) /* select into table? */
- res = SPI_OK_SELINTO;
- else if (queryDesc->dest->mydest != DestSPI)
+ if (queryDesc->dest->mydest != DestSPI)
{
/* Don't return SPI_OK_SELECT if we're discarding result */
res = SPI_OK_UTILITY;
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 7fec4db..e4f1815 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -85,7 +85,6 @@ _copyPlannedStmt(const PlannedStmt *from)
COPY_NODE_FIELD(rtable);
COPY_NODE_FIELD(resultRelations);
COPY_NODE_FIELD(utilityStmt);
- COPY_NODE_FIELD(intoClause);
COPY_NODE_FIELD(subplans);
COPY_BITMAPSET_FIELD(rewindPlanIDs);
COPY_NODE_FIELD(rowMarks);
@@ -2419,7 +2418,6 @@ _copyQuery(const Query *from)
COPY_SCALAR_FIELD(canSetTag);
COPY_NODE_FIELD(utilityStmt);
COPY_SCALAR_FIELD(resultRelation);
- COPY_NODE_FIELD(intoClause);
COPY_SCALAR_FIELD(hasAggs);
COPY_SCALAR_FIELD(hasWindowFuncs);
COPY_SCALAR_FIELD(hasSubLinks);
@@ -3207,6 +3205,18 @@ _copyExplainStmt(const ExplainStmt *from)
return newnode;
}
+static CreateTableAsStmt *
+_copyCreateTableAsStmt(CreateTableAsStmt *from)
+{
+ CreateTableAsStmt *newnode = makeNode(CreateTableAsStmt);
+
+ COPY_NODE_FIELD(query);
+ COPY_NODE_FIELD(into);
+ COPY_SCALAR_FIELD(is_select_into);
+
+ return newnode;
+}
+
static CreateSeqStmt *
_copyCreateSeqStmt(const CreateSeqStmt *from)
{
@@ -3615,7 +3625,6 @@ _copyExecuteStmt(const ExecuteStmt *from)
ExecuteStmt *newnode = makeNode(ExecuteStmt);
COPY_STRING_FIELD(name);
- COPY_NODE_FIELD(into);
COPY_NODE_FIELD(params);
return newnode;
@@ -4250,6 +4259,9 @@ copyObject(const void *from)
case T_ExplainStmt:
retval = _copyExplainStmt(from);
break;
+ case T_CreateTableAsStmt:
+ retval = _copyCreateTableAsStmt(from);
+ break;
case T_CreateSeqStmt:
retval = _copyCreateSeqStmt(from);
break;
diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c
index d2a79eb..4ac895e 100644
--- a/src/backend/nodes/equalfuncs.c
+++ b/src/backend/nodes/equalfuncs.c
@@ -900,7 +900,6 @@ _equalQuery(const Query *a, const Query *b)
COMPARE_SCALAR_FIELD(canSetTag);
COMPARE_NODE_FIELD(utilityStmt);
COMPARE_SCALAR_FIELD(resultRelation);
- COMPARE_NODE_FIELD(intoClause);
COMPARE_SCALAR_FIELD(hasAggs);
COMPARE_SCALAR_FIELD(hasWindowFuncs);
COMPARE_SCALAR_FIELD(hasSubLinks);
@@ -1564,6 +1563,17 @@ _equalExplainStmt(const ExplainStmt *a, const ExplainStmt *b)
return true;
}
+
+static bool
+_equalCreateTableAsStmt(CreateTableAsStmt *a, CreateTableAsStmt *b)
+{
+ COMPARE_NODE_FIELD(query);
+ COMPARE_NODE_FIELD(into);
+ COMPARE_SCALAR_FIELD(is_select_into);
+
+ return true;
+}
+
static bool
_equalCreateSeqStmt(const CreateSeqStmt *a, const CreateSeqStmt *b)
{
@@ -1908,7 +1918,6 @@ static bool
_equalExecuteStmt(const ExecuteStmt *a, const ExecuteStmt *b)
{
COMPARE_STRING_FIELD(name);
- COMPARE_NODE_FIELD(into);
COMPARE_NODE_FIELD(params);
return true;
@@ -2793,6 +2802,9 @@ equal(const void *a, const void *b)
case T_ExplainStmt:
retval = _equalExplainStmt(a, b);
break;
+ case T_CreateTableAsStmt:
+ retval = _equalCreateTableAsStmt(a, b);
+ break;
case T_CreateSeqStmt:
retval = _equalCreateSeqStmt(a, b);
break;
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nodes/outfuncs.c
index 25a215e..9cb8592 100644
--- a/src/backend/nodes/outfuncs.c
+++ b/src/backend/nodes/outfuncs.c
@@ -248,7 +248,6 @@ _outPlannedStmt(StringInfo str, const PlannedStmt *node)
WRITE_NODE_FIELD(rtable);
WRITE_NODE_FIELD(resultRelations);
WRITE_NODE_FIELD(utilityStmt);
- WRITE_NODE_FIELD(intoClause);
WRITE_NODE_FIELD(subplans);
WRITE_BITMAPSET_FIELD(rewindPlanIDs);
WRITE_NODE_FIELD(rowMarks);
@@ -2187,7 +2186,6 @@ _outQuery(StringInfo str, const Query *node)
appendStringInfo(str, " :utilityStmt <>");
WRITE_INT_FIELD(resultRelation);
- WRITE_NODE_FIELD(intoClause);
WRITE_BOOL_FIELD(hasAggs);
WRITE_BOOL_FIELD(hasWindowFuncs);
WRITE_BOOL_FIELD(hasSubLinks);
@@ -2805,7 +2803,7 @@ _outNode(StringInfo str, const void *obj)
case T_RangeVar:
_outRangeVar(str, obj);
break;
- case T_IntoClause:
+ case T_IntoClause:/*XXX: This could be removed but dim would need to add it right back*/
_outIntoClause(str, obj);
break;
case T_Var:
diff --git a/src/backend/nodes/readfuncs.c b/src/backend/nodes/readfuncs.c
index b9258ad..9b57956 100644
--- a/src/backend/nodes/readfuncs.c
+++ b/src/backend/nodes/readfuncs.c
@@ -198,7 +198,6 @@ _readQuery(void)
READ_BOOL_FIELD(canSetTag);
READ_NODE_FIELD(utilityStmt);
READ_INT_FIELD(resultRelation);
- READ_NODE_FIELD(intoClause);
READ_BOOL_FIELD(hasAggs);
READ_BOOL_FIELD(hasWindowFuncs);
READ_BOOL_FIELD(hasSubLinks);
diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 8bbe977..6b0541b 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -233,7 +233,6 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
result->rtable = glob->finalrtable;
result->resultRelations = glob->resultRelations;
result->utilityStmt = parse->utilityStmt;
- result->intoClause = parse->intoClause;
result->subplans = glob->subplans;
result->rewindPlanIDs = glob->rewindPlanIDs;
result->rowMarks = glob->finalrowmarks;
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 40a420a..8006787 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -1399,7 +1399,6 @@ simplify_EXISTS_query(Query *query)
* are complex.
*/
if (query->commandType != CMD_SELECT ||
- query->intoClause ||
query->setOperations ||
query->hasAggs ||
query->hasWindowFuncs ||
diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
index 59a5268..0304c9d 100644
--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -1129,8 +1129,7 @@ is_simple_subquery(Query *subquery)
*/
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/*
@@ -1216,8 +1215,7 @@ is_simple_union_all(Query *subquery)
/* Let's just make sure it's a valid subselect ... */
if (!IsA(subquery, Query) ||
subquery->commandType != CMD_SELECT ||
- subquery->utilityStmt != NULL ||
- subquery->intoClause != NULL)
+ subquery->utilityStmt != NULL)
elog(ERROR, "subquery is bogus");
/* Is it a set-operation query at all? */
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index cd3da46..7d40e3e 100644
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -4168,7 +4168,6 @@ inline_function(Oid funcid, Oid result_type, Oid result_collid,
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
querytree->utilityStmt ||
- querytree->intoClause ||
querytree->hasAggs ||
querytree->hasWindowFuncs ||
querytree->hasSubLinks ||
@@ -4682,8 +4681,7 @@ inline_set_returning_function(PlannerInfo *root, RangeTblEntry *rte)
*/
if (!IsA(querytree, Query) ||
querytree->commandType != CMD_SELECT ||
- querytree->utilityStmt ||
- querytree->intoClause)
+ querytree->utilityStmt)
goto fail;
/*
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c
index b187b03..182d6f7 100644
--- a/src/backend/parser/analyze.c
+++ b/src/backend/parser/analyze.c
@@ -62,6 +62,8 @@ static Query *transformDeclareCursorStmt(ParseState *pstate,
DeclareCursorStmt *stmt);
static Query *transformExplainStmt(ParseState *pstate,
ExplainStmt *stmt);
+static Query *transformCreateTableAsStmt(ParseState *pstate,
+ CreateTableAsStmt *stmt);
static void transformLockingClause(ParseState *pstate, Query *qry,
LockingClause *lc, bool pushedDown);
@@ -202,6 +204,11 @@ transformStmt(ParseState *pstate, Node *parseTree)
(ExplainStmt *) parseTree);
break;
+ case T_CreateTableAsStmt:
+ result = transformCreateTableAsStmt(pstate,
+ (CreateTableAsStmt *) parseTree);
+ break;
+
default:
/*
@@ -257,6 +264,7 @@ analyze_requires_snapshot(Node *parseTree)
result = true;
break;
+ case T_CreateTableAsStmt:
case T_ExplainStmt:
/* yes, because we must analyze the contained statement */
result = true;
@@ -455,21 +463,29 @@ transformInsertStmt(ParseState *pstate, InsertStmt *stmt)
sub_pstate->p_relnamespace = sub_relnamespace;
sub_pstate->p_varnamespace = sub_varnamespace;
+ /* The grammar should have produced a SELECT, but it might have INTO */
+ if(IsA(stmt->selectStmt, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->selectStmt;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INSERT ... SELECT cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
selectQuery = transformStmt(sub_pstate, stmt->selectStmt);
free_parsestate(sub_pstate);
- /* The grammar should have produced a SELECT, but it might have INTO */
if (!IsA(selectQuery, Query) ||
selectQuery->commandType != CMD_SELECT ||
selectQuery->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in INSERT ... SELECT");
- if (selectQuery->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("INSERT ... SELECT cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) selectQuery->intoClause))));
/*
* Make the source be a subquery in the INSERT's rangetable, and add
@@ -876,6 +892,18 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
Node *qual;
ListCell *l;
+ /*
+ * Validity-check whether we got called from somewhere where
+ * ... INTO was not allowed
+ */
+ if (stmt->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("INTO is only allowed on first SELECT of UNION/INTERSECT/EXCEPT"),
+ parser_errposition(pstate,
+ exprLocation((Node *) stmt->intoClause))));
+
+
qry->commandType = CMD_SELECT;
/* process the WITH clause independently of all else */
@@ -963,8 +991,6 @@ transformSelectStmt(ParseState *pstate, SelectStmt *stmt)
pstate->p_windowdefs,
&qry->targetList);
- /* SELECT INTO/CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
qry->rtable = pstate->p_rtable;
qry->jointree = makeFromExpr(pstate->p_joinlist, qual);
@@ -1185,9 +1211,6 @@ transformValuesClause(ParseState *pstate, SelectStmt *stmt)
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("SELECT FOR UPDATE/SHARE cannot be applied to VALUES")));
- /* CREATE TABLE AS spec is just passed through */
- qry->intoClause = stmt->intoClause;
-
/*
* There mustn't have been any table references in the expressions, else
* strange things would happen, like Cartesian products of those tables
@@ -1253,7 +1276,6 @@ static Query *
transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
{
Query *qry = makeNode(Query);
- SelectStmt *leftmostSelect;
int leftmostRTI;
Query *leftmostQuery;
SetOperationStmt *sostmt;
@@ -1286,20 +1308,6 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
}
/*
- * Find leftmost leaf SelectStmt; extract the one-time-only items from it
- * and from the top-level node.
- */
- leftmostSelect = stmt->larg;
- while (leftmostSelect && leftmostSelect->op != SETOP_NONE)
- leftmostSelect = leftmostSelect->larg;
- Assert(leftmostSelect && IsA(leftmostSelect, SelectStmt) &&
- leftmostSelect->larg == NULL);
- qry->intoClause = leftmostSelect->intoClause;
-
- /* clear this to prevent complaints in transformSetOperationTree() */
- leftmostSelect->intoClause = NULL;
-
- /*
* These are not one-time, exactly, but we want to process them here and
* not let transformSetOperationTree() see them --- else it'll just
* recurse right back here!
@@ -1330,7 +1338,7 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
qry->setOperations = (Node *) sostmt;
/*
- * Re-find leftmost SELECT (now it's a sub-query in rangetable)
+ * Find leftmost SELECT (it's a sub-query in rangetable)
*/
node = sostmt->larg;
while (node && IsA(node, SetOperationStmt))
@@ -2099,6 +2107,25 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
(errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
errmsg("cannot specify both SCROLL and NO SCROLL")));
+ /*
+ * We must explicitly disallow DECLARE CURSOR ... SELECT INTO We
+ * have to do this before transformStmt() as that will holler if
+ * it ever finds a intoClause
+ */
+ if(IsA(stmt->query, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)stmt->query;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
+ errmsg("DECLARE CURSOR cannot specify INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
result = transformStmt(pstate, stmt->query);
/* Grammar should not have allowed anything but SELECT */
@@ -2107,14 +2134,6 @@ transformDeclareCursorStmt(ParseState *pstate, DeclareCursorStmt *stmt)
result->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in DECLARE CURSOR");
- /* But we must explicitly disallow DECLARE CURSOR ... SELECT INTO */
- if (result->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_INVALID_CURSOR_DEFINITION),
- errmsg("DECLARE CURSOR cannot specify INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) result->intoClause))));
-
/*
* We also disallow data-modifying WITH in a cursor. (This could be
* allowed, but the semantics of when the updates occur might be
@@ -2183,6 +2202,28 @@ transformExplainStmt(ParseState *pstate, ExplainStmt *stmt)
/*
+ * transformCreateTableAsStmt -
+ * transform an CREATE TABLE AS/SELECT ... INTO Statement
+ *
+ */
+static Query *
+transformCreateTableAsStmt(ParseState *pstate, CreateTableAsStmt *stmt)
+{
+ Query *result;
+
+ /* transform contained query */
+ stmt->query = (Node *) transformStmt(pstate, stmt->query);
+
+ /* represent the command as a utility Query */
+ result = makeNode(Query);
+ result->commandType = CMD_UTILITY;
+ result->utilityStmt = (Node *) stmt;
+
+ return result;
+}
+
+
+/*
* Check for features that are not supported together with FOR UPDATE/SHARE.
*
* exported so planner can check again after rewriting, query pullup, etc
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index d1ce2ab..2208594 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -3052,23 +3052,28 @@ ExistingIndex: USING INDEX index_name { $$ = $3; }
CreateAsStmt:
CREATE OptTemp TABLE create_as_target AS SelectStmt opt_with_data
{
+ SelectStmt *n;
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = $4;
+ ctas->query = $6;
+ ctas->is_select_into = false;
+ $4->skipData = !($7);
+ $4->rel->relpersistence = $2;
+ $4->skipData = !($7);
+ $$ = (Node*)ctas;
+
/*
* When the SelectStmt is a set-operation tree, we must
* stuff the INTO information into the leftmost component
* Select, because that's where analyze.c will expect
* to find it.
*/
- SelectStmt *n = findLeftmostSelect((SelectStmt *) $6);
+ n = findLeftmostSelect((SelectStmt *) $6);
if (n->intoClause != NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("CREATE TABLE AS cannot specify INTO"),
parser_errposition(exprLocation((Node *) n->intoClause))));
- n->intoClause = $4;
- /* cram additional flags into the IntoClause */
- $4->rel->relpersistence = $2;
- $4->skipData = !($7);
- $$ = $6;
}
;
@@ -8275,20 +8280,25 @@ ExecuteStmt: EXECUTE name execute_param_clause
ExecuteStmt *n = makeNode(ExecuteStmt);
n->name = $2;
n->params = $3;
- n->into = NULL;
$$ = (Node *) n;
}
| CREATE OptTemp TABLE create_as_target AS
EXECUTE name execute_param_clause opt_with_data
{
ExecuteStmt *n = makeNode(ExecuteStmt);
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+
n->name = $7;
n->params = $8;
- n->into = $4;
+
/* cram additional flags into the IntoClause */
$4->rel->relpersistence = $2;
$4->skipData = !($9);
- $$ = (Node *) n;
+
+ ctas->into = $4;
+ ctas->query = (Node*)n;
+ ctas->is_select_into = false;
+ $$ = (Node *) ctas;
}
;
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 7f4da92..52f449f 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -481,6 +481,21 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
if (r->alias == NULL)
elog(ERROR, "subquery in FROM must have an alias");
+
+ if(IsA(r->subquery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)r->subquery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in FROM cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *)first->intoClause))));
+ }
+
/*
* Analyze and transform the subquery.
*/
@@ -495,12 +510,6 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
query->commandType != CMD_SELECT ||
query->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in subquery in FROM");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in FROM cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
/*
* The subquery cannot make use of any variables from FROM items created
diff --git a/src/backend/parser/parse_cte.c b/src/backend/parser/parse_cte.c
index c0c6240..4ea8ee6 100644
--- a/src/backend/parser/parse_cte.c
+++ b/src/backend/parser/parse_cte.c
@@ -241,6 +241,20 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
/* Analysis not done already */
Assert(!IsA(cte->ctequery, Query));
+ if(IsA(cte->ctequery, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)cte->ctequery;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery in WITH cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
query = parse_sub_analyze(cte->ctequery, pstate, cte, false);
cte->ctequery = (Node *) query;
@@ -253,13 +267,6 @@ analyzeCTE(ParseState *pstate, CommonTableExpr *cte)
if (query->utilityStmt != NULL)
elog(ERROR, "unexpected utility statement in WITH");
- if (query->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery in WITH cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) query->intoClause))));
-
/*
* We disallow data-modifying WITH except at the top level of a query,
* because it's not clear when such a modification should be executed.
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index d22d8a1..d4d9121 100644
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1398,6 +1398,21 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
return result;
pstate->p_hasSubLinks = true;
+
+ if(IsA(sublink->subselect, SelectStmt))
+ {
+ SelectStmt* first = (SelectStmt*)sublink->subselect;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+
+ if (first->intoClause)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+ errmsg("subquery cannot have SELECT INTO"),
+ parser_errposition(pstate,
+ exprLocation((Node *) first->intoClause))));
+ }
+
qtree = parse_sub_analyze(sublink->subselect, pstate, NULL, false);
/*
@@ -1408,12 +1423,6 @@ transformSubLink(ParseState *pstate, SubLink *sublink)
qtree->commandType != CMD_SELECT ||
qtree->utilityStmt != NULL)
elog(ERROR, "unexpected non-SELECT command in SubLink");
- if (qtree->intoClause)
- ereport(ERROR,
- (errcode(ERRCODE_SYNTAX_ERROR),
- errmsg("subquery cannot have SELECT INTO"),
- parser_errposition(pstate,
- exprLocation((Node *) qtree->intoClause))));
sublink->subselect = (Node *) qtree;
diff --git a/src/backend/parser/parser.c b/src/backend/parser/parser.c
index f9ec2b2..854925c 100644
--- a/src/backend/parser/parser.c
+++ b/src/backend/parser/parser.c
@@ -37,6 +37,7 @@ raw_parser(const char *str)
core_yyscan_t yyscanner;
base_yy_extra_type yyextra;
int yyresult;
+ ListCell *c;
/* initialize the flex scanner */
yyscanner = scanner_init(str, &yyextra.core_yy_extra,
@@ -57,6 +58,43 @@ raw_parser(const char *str)
if (yyresult) /* error */
return NIL;
+ /*
+ * Some things are rather hard to properly diagnose in grammar
+ * without complicating/duplicating it too much. So we do some
+ * postprocessing here.
+ */
+ foreach(c, yyextra.parsetree){
+ switch(nodeTag(lfirst(c))){
+ /*
+ * The grammar currently doesn't disambiguate between
+ * SELECT and SELECT ... INTO. Do that now.
+ */
+ case T_SelectStmt:
+ {
+ SelectStmt* s = (SelectStmt*)lfirst(c);
+ SelectStmt* first = s;
+ while (first && first->op != SETOP_NONE)
+ first = first->larg;
+ Assert(first && IsA(first, SelectStmt) && first->larg == NULL);
+ if(first->intoClause){
+ CreateTableAsStmt* ctas = makeNode(CreateTableAsStmt);
+ ctas->into = first->intoClause;
+ ctas->query = (Node*)s;
+ ctas->is_select_into = true;
+ /*
+ * this way everyone can complain if this is set
+ * without further checks because it shall never
+ * be set but here.
+ */
+ first->intoClause = NULL;
+ lfirst(c) = ctas;
+ break;
+ }
+ }
+ default:
+ break;
+ }
+ }
return yyextra.parsetree;
}
diff --git a/src/backend/rewrite/rewriteDefine.c b/src/backend/rewrite/rewriteDefine.c
index 8c87ac5..24199e8 100644
--- a/src/backend/rewrite/rewriteDefine.c
+++ b/src/backend/rewrite/rewriteDefine.c
@@ -323,8 +323,7 @@ DefineQueryRewrite(char *rulename,
query = (Query *) linitial(action);
if (!is_instead ||
query->commandType != CMD_SELECT ||
- query->utilityStmt != NULL ||
- query->intoClause != NULL)
+ query->utilityStmt != NULL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("rules on SELECT must have action INSTEAD SELECT")));
diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index 42a0fb0..7c50284 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -260,8 +260,7 @@ ChoosePortalStrategy(List *stmts)
if (query->canSetTag)
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
{
if (query->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -285,8 +284,7 @@ ChoosePortalStrategy(List *stmts)
if (pstmt->canSetTag)
{
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
{
if (pstmt->hasModifyingCTE)
return PORTAL_ONE_MOD_WITH;
@@ -395,8 +393,7 @@ FetchStatementTargetList(Node *stmt)
else
{
if (query->commandType == CMD_SELECT &&
- query->utilityStmt == NULL &&
- query->intoClause == NULL)
+ query->utilityStmt == NULL)
return query->targetList;
if (query->returningList)
return query->returningList;
@@ -408,8 +405,7 @@ FetchStatementTargetList(Node *stmt)
PlannedStmt *pstmt = (PlannedStmt *) stmt;
if (pstmt->commandType == CMD_SELECT &&
- pstmt->utilityStmt == NULL &&
- pstmt->intoClause == NULL)
+ pstmt->utilityStmt == NULL)
return pstmt->planTree->targetlist;
if (pstmt->hasReturning)
return pstmt->planTree->targetlist;
@@ -430,7 +426,6 @@ FetchStatementTargetList(Node *stmt)
ExecuteStmt *estmt = (ExecuteStmt *) stmt;
PreparedStatement *entry;
- Assert(!estmt->into);
entry = FetchPreparedStatement(estmt->name, true);
return FetchPreparedStatementTargetList(entry);
}
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 5b81c0b..35ccdb3 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -127,9 +127,7 @@ CommandIsReadOnly(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- return false; /* SELECT INTO */
- else if (stmt->rowMarks != NIL)
+ if (stmt->rowMarks != NIL)
return false; /* SELECT FOR UPDATE/SHARE */
else if (stmt->hasModifyingCTE)
return false; /* data-modifying CTE */
@@ -198,6 +196,7 @@ check_xact_readonly(Node *parsetree)
case T_CreateSchemaStmt:
case T_CreateSeqStmt:
case T_CreateStmt:
+ case T_CreateTableAsStmt:
case T_CreateTableSpaceStmt:
case T_CreateTrigStmt:
case T_CompositeTypeStmt:
@@ -1036,6 +1035,10 @@ standard_ProcessUtility(Node *parsetree,
ExplainQuery((ExplainStmt *) parsetree, queryString, params, dest);
break;
+ case T_CreateTableAsStmt:
+ CreateTableAs((CreateTableAsStmt *) parsetree, queryString, params, dest);
+ break;
+
case T_VariableSetStmt:
ExecSetVariableStmt((VariableSetStmt *) parsetree);
break;
@@ -1230,8 +1233,6 @@ UtilityReturnsTuples(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return false;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return false; /* not our business to raise error */
@@ -1282,8 +1283,6 @@ UtilityTupleDescriptor(Node *parsetree)
ExecuteStmt *stmt = (ExecuteStmt *) parsetree;
PreparedStatement *entry;
- if (stmt->into)
- return NULL;
entry = FetchPreparedStatement(stmt->name, false);
if (!entry)
return NULL; /* not our business to raise error */
@@ -1318,8 +1317,7 @@ QueryReturnsTuples(Query *parsetree)
{
case CMD_SELECT:
/* returns tuples ... unless it's DECLARE CURSOR or SELECT INTO */
- if (parsetree->utilityStmt == NULL &&
- parsetree->intoClause == NULL)
+ if (parsetree->utilityStmt == NULL)
return true;
break;
case CMD_INSERT:
@@ -1907,6 +1905,13 @@ CreateCommandTag(Node *parsetree)
tag = "EXPLAIN";
break;
+ case T_CreateTableAsStmt:
+ if (((CreateTableAsStmt*)parsetree)->is_select_into)
+ tag = "SELECT INTO";
+ else
+ tag = "CREATE TABLE AS";
+ break;
+
case T_VariableSetStmt:
switch (((VariableSetStmt *) parsetree)->kind)
{
@@ -2060,8 +2065,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2110,8 +2113,6 @@ CreateCommandTag(Node *parsetree)
Assert(IsA(stmt->utilityStmt, DeclareCursorStmt));
tag = "DECLARE CURSOR";
}
- else if (stmt->intoClause != NULL)
- tag = "SELECT INTO";
else if (stmt->rowMarks != NIL)
{
/* not 100% but probably close enough */
@@ -2178,10 +2179,7 @@ GetCommandLogLevel(Node *parsetree)
break;
case T_SelectStmt:
- if (((SelectStmt *) parsetree)->intoClause)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL;
+ lev = LOGSTMT_ALL;
break;
/* utility statements --- same whether raw or cooked */
@@ -2429,6 +2427,10 @@ GetCommandLogLevel(Node *parsetree)
}
break;
+ case T_CreateTableAsStmt:
+ lev = LOGSTMT_DDL;
+ break;
+
case T_VariableSetStmt:
lev = LOGSTMT_ALL;
break;
@@ -2529,10 +2531,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
@@ -2558,10 +2557,7 @@ GetCommandLogLevel(Node *parsetree)
switch (stmt->commandType)
{
case CMD_SELECT:
- if (stmt->intoClause != NULL)
- lev = LOGSTMT_DDL; /* CREATE AS, SELECT INTO */
- else
- lev = LOGSTMT_ALL; /* SELECT or DECLARE CURSOR */
+ lev = LOGSTMT_ALL;
break;
case CMD_UPDATE:
diff --git a/src/include/access/htup.h b/src/include/access/htup.h
index 6a3778d..abbc152 100644
--- a/src/include/access/htup.h
+++ b/src/include/access/htup.h
@@ -311,7 +311,7 @@ do { \
#define HeapTupleHeaderSetOid(tup, oid) \
do { \
- Assert((tup)->t_infomask & HEAP_HASOID); \
+ if(!((tup)->t_infomask & HEAP_HASOID)) elog(ERROR, "HEAP_HASOID"); \
*((Oid *) ((char *)(tup) + (tup)->t_hoff - sizeof(Oid))) = (oid); \
} while (0)
diff --git a/src/include/commands/prepare.h b/src/include/commands/prepare.h
index 472a357..6b545dc 100644
--- a/src/include/commands/prepare.h
+++ b/src/include/commands/prepare.h
@@ -54,4 +54,7 @@ extern List *FetchPreparedStatementTargetList(PreparedStatement *stmt);
void DropAllPreparedStatements(void);
+extern ParamListInfo EvaluateParams(PreparedStatement *pstmt, List *params,
+ const char *queryString, EState *estate);
+
#endif /* PREPARE_H */
diff --git a/src/include/commands/tablecmds.h b/src/include/commands/tablecmds.h
index 03f397d..212a51d 100644
--- a/src/include/commands/tablecmds.h
+++ b/src/include/commands/tablecmds.h
@@ -15,6 +15,7 @@
#define TABLECMDS_H
#include "access/htup.h"
+#include "executor/executor.h"
#include "nodes/parsenodes.h"
#include "storage/lock.h"
#include "utils/relcache.h"
@@ -22,6 +23,9 @@
extern Oid DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId);
+extern void CreateTableAs(CreateTableAsStmt *stmt, const char *queryString,
+ ParamListInfo params, DestReceiver *dest);
+
extern void RemoveRelations(DropStmt *drop);
extern Oid AlterTableLookupRelation(AlterTableStmt *stmt, LOCKMODE lockmode);
diff --git a/src/include/executor/executor.h b/src/include/executor/executor.h
index 7f27669..47bd1ee 100644
--- a/src/include/executor/executor.h
+++ b/src/include/executor/executor.h
@@ -49,12 +49,17 @@
* AfterTriggerBeginQuery/AfterTriggerEndQuery. This does not necessarily
* mean that the plan can't queue any AFTER triggers; just that the caller
* is responsible for there being a trigger context for them to be queued in.
+ *
+ * FORCE_OIDS tells the executor to build a tupleDesc that includes
+ * the oid column. This is used from tablecmd.c's CreateTableAs.
*/
#define EXEC_FLAG_EXPLAIN_ONLY 0x0001 /* EXPLAIN, no ANALYZE */
#define EXEC_FLAG_REWIND 0x0002 /* need efficient rescan */
#define EXEC_FLAG_BACKWARD 0x0004 /* need backward scan */
#define EXEC_FLAG_MARK 0x0008 /* need mark/restore */
#define EXEC_FLAG_SKIP_TRIGGERS 0x0010 /* skip AfterTrigger calls */
+#define EXEC_FLAG_FORCE_OIDS_ON 0x0020 /* force oids in returned tuples */
+#define EXEC_FLAG_FORCE_OIDS_OFF 0x0040 /* force oids in returned tuples */
/*
diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 5207102..d268fb9 100644
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -322,6 +322,12 @@ typedef struct ResultRelInfo
ProjectionInfo *ri_projectReturning;
} ResultRelInfo;
+typedef enum {
+ ESTATE_FORCE_OIDS_DEFAULT,
+ ESTATE_FORCE_OIDS_ON,
+ ESTATE_FORCE_OIDS_OFF
+} EStateForceOids;
+
/* ----------------
* EState information
*
@@ -371,8 +377,7 @@ typedef struct EState
int es_top_eflags; /* eflags passed to ExecutorStart */
int es_instrument; /* OR of InstrumentOption flags */
- bool es_select_into; /* true if doing SELECT INTO */
- bool es_into_oids; /* true to generate OIDs in SELECT INTO */
+ EStateForceOids es_force_oids; /* used by CreateTableAs */
bool es_finished; /* true when ExecutorFinish is done */
List *es_exprcontexts; /* List of ExprContexts within EState */
diff --git a/src/include/nodes/nodes.h b/src/include/nodes/nodes.h
index 0e7d184..f4d9ce2 100644
--- a/src/include/nodes/nodes.h
+++ b/src/include/nodes/nodes.h
@@ -304,6 +304,7 @@ typedef enum NodeTag
T_DropdbStmt,
T_VacuumStmt,
T_ExplainStmt,
+ T_CreateTableAsStmt,
T_CreateSeqStmt,
T_AlterSeqStmt,
T_VariableSetStmt,
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index ab55639..5c2797c 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -111,8 +111,6 @@ typedef struct Query
int resultRelation; /* rtable index of target relation for
* INSERT/UPDATE/DELETE; 0 for SELECT */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
bool hasAggs; /* has aggregates in tlist or havingQual */
bool hasWindowFuncs; /* has window functions in tlist */
bool hasSubLinks; /* has subquery SubLink */
@@ -1009,7 +1007,7 @@ typedef struct SelectStmt
*/
List *distinctClause; /* NULL, list of DISTINCT ON exprs, or
* lcons(NIL,NIL) for all (SELECT DISTINCT) */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
+ IntoClause *intoClause; /* target for SELECT INTO */
List *targetList; /* the target list (of ResTarget) */
List *fromClause; /* the FROM clause */
Node *whereClause; /* WHERE qualification */
@@ -2384,7 +2382,7 @@ typedef struct VacuumStmt
* Explain Statement
*
* The "query" field is either a raw parse tree (SelectStmt, InsertStmt, etc)
- * or a Query node if parse analysis has been done. Note that rewriting and
+ * or a Query node if parse analysis has been done. Note that rewriting and
* planning of the query are always postponed until execution of EXPLAIN.
* ----------------------
*/
@@ -2396,6 +2394,19 @@ typedef struct ExplainStmt
} ExplainStmt;
/* ----------------------
+ * analyzing, rewriting and planning are handled as in explain
+ * statements (see comment above) only that query can only be a
+ * SelectStmt and not some other type.
+ */
+typedef struct CreateTableAsStmt
+{
+ NodeTag type;
+ IntoClause *into;
+ Node *query; /* the query (see comments above) */
+ bool is_select_into; /* plpgsql wants to disambiguate */
+} CreateTableAsStmt;
+
+/* ----------------------
* Checkpoint Statement
* ----------------------
*/
@@ -2509,7 +2520,6 @@ typedef struct ExecuteStmt
{
NodeTag type;
char *name; /* The name of the plan to execute */
- IntoClause *into; /* Optional table to store results in */
List *params; /* Values to assign to parameters */
} ExecuteStmt;
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 7d90b91..b67d988 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -54,8 +54,6 @@ typedef struct PlannedStmt
Node *utilityStmt; /* non-null if this is DECLARE CURSOR */
- IntoClause *intoClause; /* target for SELECT INTO / CREATE TABLE AS */
-
List *subplans; /* Plan trees for SubPlan expressions */
Bitmapset *rewindPlanIDs; /* indices of subplans that require REWIND */
diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c
index 0b126a3..231210a 100644
--- a/src/pl/plpgsql/src/pl_exec.c
+++ b/src/pl/plpgsql/src/pl_exec.c
@@ -3286,29 +3286,18 @@ exec_stmt_dynexecute(PLpgSQL_execstate *estate,
break;
case SPI_OK_SELINTO:
-
/*
* We want to disallow SELECT INTO for now, because its behavior
* is not consistent with SELECT INTO in a normal plpgsql context.
* (We need to reimplement EXECUTE to parse the string as a
* plpgsql command, not just feed it to SPI_execute.) However,
- * CREATE AS should be allowed ... and since it produces the same
- * parsetree as SELECT INTO, there's no way to tell the difference
- * except to look at the source text. Wotta kluge!
+ * CREATE AS should be allowed ...
*/
- {
- char *ptr;
-
- for (ptr = querystr; *ptr; ptr++)
- if (!scanner_isspace(*ptr))
- break;
- if (*ptr == 'S' || *ptr == 's')
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("EXECUTE of SELECT ... INTO is not implemented"),
- errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
- break;
- }
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("EXECUTE of SELECT ... INTO is not implemented"),
+ errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
+ break;
/* Some SPI errors deserve specific error messages */
case SPI_ERROR_COPY:
@@ -5759,7 +5748,7 @@ exec_simple_check_plan(PLpgSQL_expr *expr)
*/
if (!IsA(query, Query))
return;
- if (query->commandType != CMD_SELECT || query->intoClause)
+ if (query->commandType != CMD_SELECT)
return;
if (query->rtable != NIL)
return;
@@ -5833,7 +5822,7 @@ exec_simple_recheck_plan(PLpgSQL_expr *expr, CachedPlan *cplan)
*/
if (!IsA(stmt, PlannedStmt))
return;
- if (stmt->commandType != CMD_SELECT || stmt->intoClause)
+ if (stmt->commandType != CMD_SELECT)
return;
plan = stmt->planTree;
if (!IsA(plan, Result))
diff --git a/src/test/regress/expected/select_into.out b/src/test/regress/expected/select_into.out
index c8327f6..d124382 100644
--- a/src/test/regress/expected/select_into.out
+++ b/src/test/regress/expected/select_into.out
@@ -44,6 +44,25 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
AS SELECT oid,relname,relacl FROM pg_class
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ERROR: DECLARE CURSOR cannot specify INTO
+LINE 1: DECLARE foo CURSOR FOR SELECT 1 INTO b;
+ ^
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+ERROR: COPY (SELECT INTO) is not supported
+SELECT * FROM (SELECT 1 INTO f) bar;
+ERROR: subquery in FROM cannot have SELECT INTO
+LINE 1: SELECT * FROM (SELECT 1 INTO f) bar;
+ ^
+CREATE VIEW foo AS SELECT 1 INTO b;
+ERROR: views must not contain SELECT INTO
+INSERT INTO b SELECT 1 INTO f;
+ERROR: INSERT ... SELECT cannot specify INTO
+LINE 1: INSERT INTO b SELECT 1 INTO f;
+ ^
DROP SCHEMA selinto_schema CASCADE;
NOTICE: drop cascades to 3 other objects
DETAIL: drop cascades to table selinto_schema.tmp1
diff --git a/src/test/regress/expected/transactions.out b/src/test/regress/expected/transactions.out
index e9d3908..6981692 100644
--- a/src/test/regress/expected/transactions.out
+++ b/src/test/regress/expected/transactions.out
@@ -139,7 +139,7 @@ SELECT * FROM writetest, temptest; -- ok
(0 rows)
CREATE TABLE test AS SELECT * FROM writetest; -- fail
-ERROR: cannot execute SELECT INTO in a read-only transaction
+ERROR: cannot execute CREATE TABLE AS in a read-only transaction
START TRANSACTION READ WRITE;
DROP TABLE writetest; -- ok
COMMIT;
diff --git a/src/test/regress/sql/select_into.sql b/src/test/regress/sql/select_into.sql
index 09d210b..0c07f76 100644
--- a/src/test/regress/sql/select_into.sql
+++ b/src/test/regress/sql/select_into.sql
@@ -50,6 +50,21 @@ CREATE TABLE selinto_schema.tmp3 (a,b,c)
WHERE relname like '%c%'; -- OK
RESET SESSION AUTHORIZATION;
+
+--
+-- disallowed uses of SELECT ... INTO. All should fail
+--
+DECLARE foo CURSOR FOR SELECT 1 INTO b;
+
+COPY (SELECT 1 INTO frak UNION SELECT 2) TO 'blub';
+
+SELECT * FROM (SELECT 1 INTO f) bar;
+
+CREATE VIEW foo AS SELECT 1 INTO b;
+
+INSERT INTO b SELECT 1 INTO f;
+
+
DROP SCHEMA selinto_schema CASCADE;
DROP USER selinto_user;
--
1.7.6.409.ge7a85.dirty
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-02-27 23:32 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-02-28 00:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 00:29 ` Re: Command Triggers, patch v11 anarazel@anarazel.de <andres@anarazel.de>
0 siblings, 1 reply; 115+ messages in thread
From: Tom Lane @ 2012-02-28 00:21 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Andres Freund <andres@anarazel.de> writes:
> I refreshed the patch so it works again on current HEAD. Basically some
> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The latter doesn't
> seem necessary to me after the changes, so I simply ditched it. Am I missing
> something?
No, that was only needed because execMain.c was overriding somebody
else's tuple receiver. If you're putting the right receiver into the
QueryDesc to start with, it shouldn't be necessary.
I'm confused by this though:
> This basically includes a revert of d8fb1f9adbddd1eef123d66a89a9fc0ecd96f60b
I don't find that commit ID anywhere.
regards, tom lane
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:00 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:19 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-02-27 23:32 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-02-28 00:21 ` Re: Command Triggers, patch v11 Tom Lane <tgl@sss.pgh.pa.us>
@ 2012-02-28 00:29 ` anarazel@anarazel.de <andres@anarazel.de>
0 siblings, 0 replies; 115+ messages in thread
From: anarazel@anarazel.de @ 2012-02-28 00:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Tom Lane <tgl@sss.pgh.pa.us> schrieb:
>Andres Freund <andres@anarazel.de> writes:
>> I refreshed the patch so it works again on current HEAD. Basically
>some
>> trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The
>latter doesn't
>> seem necessary to me after the changes, so I simply ditched it. Am I
>missing
>> something?
>
>No, that was only needed because execMain.c was overriding somebody
>else's tuple receiver. If you're putting the right receiver into the
>QueryDesc to start with, it shouldn't be necessary.
>
>I'm confused by this though:
>
>> This basically includes a revert of
>d8fb1f9adbddd1eef123d66a89a9fc0ecd96f60b
>
>I don't find that commit ID anywhere.
That should have been the aforementioned commit. Must have screwed up the copy&paste buffer. Sorry for that.
Andres
Please excuse the brevity and formatting - I am writing this on my mobile phone.
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-13 11:22 ` Andres Freund <andres@anarazel.de>
2012-03-13 15:14 ` Re: Command Triggers, patch v11 Alvaro Herrera <alvherre@commandprompt.com>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
1 sibling, 2 replies; 115+ messages in thread
From: Andres Freund @ 2012-03-13 11:22 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Hi,
I did a short review of what I found after merging master
(b4af1c25bbc636379efc5d2ffb9d420765705b8a) to what I currently fetched from
your repo (d63df64580114de4d83cfe8eb45eb630724b8b6f).
- I still find it strange not to fire on cascading actions
- I dislike the missing locking leading to strange errors uppon concurrent
changes. But then thats just about all the rest of commands/* is handling
it...
T1:
BEGIN;
ALTER COMMAND TRIGGER cmd_before SET DISABLE;
T2:
BEGIN;
ALTER COMMAND TRIGGER cmd_before SET DISABLE;
T1:
COMMIT;
T2:
ERROR: tuple concurrently updated
- I think list_command_triggers should do a heap_lock_tuple(LockTupleShared)
on the command trigger tuple. But then again just about nothing else does :(
- ExecBeforeOrInsteadOfCommandTriggers is referenced in
exec_command_triggers_internal comments
- InitCommandContext comments are outdated
- generally comments look a bit outdated
- shouldn't the command trigger stuff for ALTER TABLE be done in inside
AlterTable instead of utility.c?
- you have repetitions of the following pattern:
void
ExecBeforeCommandTriggers(CommandContext cmd)
{
/* that will execute under command trigger memory context */
if (cmd != NULL && cmd->before != NIL)
exec_command_triggers_internal(cmd, cmd->before, "BEFORE");
/* switch back to the command Memory Context now */
MemoryContextSwitchTo(cmd->oldmctx);
}
1. Either cmd != NULL does not need to be checked or you need to check it
before the MemoryContextSwitchTo
2. the switch to cmd->oldmctx made me very wary at first because I wasn't sure
its guaranteed to be non NULL
- why is there a special CommandTriggerContext if its not reset separately?
Should it be reset? I have to say that I dislike the api around this.
- an AFTER .. ALTER AGGREATE ... SET SCHEMA has the wrong schema. Probably the
same problem exists elsewhere. Or is that as-designed? Would be inconsistent
with the way object names are handled.
- what does that mean?
+ cmd.objectname = NULL; /* composite object name */
- DropPropertyStmt seems to be an unused leftover?
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-13 15:14 ` Alvaro Herrera <alvherre@commandprompt.com>
1 sibling, 0 replies; 115+ messages in thread
From: Alvaro Herrera @ 2012-03-13 15:14 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers; Dimitri Fontaine <dimitri@2ndquadrant.fr>
Excerpts from Andres Freund's message of mar mar 13 08:22:26 -0300 2012:
> - I think list_command_triggers should do a heap_lock_tuple(LockTupleShared)
> on the command trigger tuple. But then again just about nothing else does :(
If you want to do something like that, I think it's probably more
appropriate to use LockDatabaseObject than heap_lock_tuple.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-13 20:07 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
1 sibling, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-13 20:07 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@postgresql.org, Dimitri Fontaine <dimitri@2ndquadrant.fr>
Hi,
Andres Freund <andres@anarazel.de> writes:
> I did a short review of what I found after merging master
Thanks!
> - I still find it strange not to fire on cascading actions
We don't build statement for cascading so we don't fire command
triggers. The user view is that there was no drop command on the sub
objects, only on the main one.
I know it's not ideal, but that's a limit we have to bite for 9.2
unfortunately.
> - I dislike the missing locking leading to strange errors uppon concurrent
> changes. But then thats just about all the rest of commands/* is handling
> it...
>
> - I think list_command_triggers should do a heap_lock_tuple(LockTupleShared)
> on the command trigger tuple. But then again just about nothing else does :(
As you say, about nothing else does. I think that's a work for another
patch.
> - ExecBeforeOrInsteadOfCommandTriggers is referenced in
> exec_command_triggers_internal comments
> - InitCommandContext comments are outdated
> - generally comments look a bit outdated
Fixed.
> - shouldn't the command trigger stuff for ALTER TABLE be done in inside
> AlterTable instead of utility.c?
Right, done.
> - you have repetitions of the following pattern:
> void
> ExecBeforeCommandTriggers(CommandContext cmd)
> {
> /* that will execute under command trigger memory context */
> if (cmd != NULL && cmd->before != NIL)
> exec_command_triggers_internal(cmd, cmd->before, "BEFORE");
>
> /* switch back to the command Memory Context now */
> MemoryContextSwitchTo(cmd->oldmctx);
> }
>
> 1. Either cmd != NULL does not need to be checked or you need to check it
> before the MemoryContextSwitchTo
I've fixed that code.
> 2. the switch to cmd->oldmctx made me very wary at first because I wasn't sure
> its guaranteed to be non NULL
>
> - why is there a special CommandTriggerContext if its not reset separately?
> Should it be reset? I have to say that I dislike the api around this.
Some call sites need to be able to call those functions a dynamic number
of times. I could add a reset boolean parameter that would mostly be
true in all call site and false in two of them (RemoveObjects,
RemoveRelations), and add a new function to just reset the memory
context then.
Or maybe you have a better idea about the ideal API here?
> - an AFTER .. ALTER AGGREATE ... SET SCHEMA has the wrong schema. Probably the
> same problem exists elsewhere. Or is that as-designed? Would be inconsistent
> with the way object names are handled.
I'm surprised, here's an excerpt from the added regression tests:
alter function notfun(int) set schema cmd;
NOTICE: snitch: BEFORE any ALTER FUNCTION
NOTICE: snitch: BEFORE ALTER FUNCTION public notfun
NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
NOTICE: snitch: AFTER any ALTER FUNCTION
> - what does that mean?
> + cmd.objectname = NULL; /* composite object name */
User mapping and casts object names are composite, and I don't know how
to represent that in a single text structure.
> - DropPropertyStmt seems to be an unused leftover?
Seems so, cleaned out.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-13 21:06 ` Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 115+ messages in thread
From: Andres Freund @ 2012-03-13 21:06 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: pgsql-hackers
On Tuesday, March 13, 2012 09:07:32 PM Dimitri Fontaine wrote:
> Hi,
>
> Andres Freund <andres@anarazel.de> writes:
> > I did a short review of what I found after merging master
>
> Thanks!
>
> > - I still find it strange not to fire on cascading actions
>
> We don't build statement for cascading so we don't fire command
> triggers. The user view is that there was no drop command on the sub
> objects, only on the main one.
>
> I know it's not ideal, but that's a limit we have to bite for 9.2
> unfortunately.
Hm. Especially in partially replicated scenarios I think that will bite. But
then: There will be a 9.3 at some point ;)
> > - I dislike the missing locking leading to strange errors uppon
> > concurrent changes. But then thats just about all the rest of commands/*
> > is handling it...
> >
> > - I think list_command_triggers should do a
> > heap_lock_tuple(LockTupleShared)
> >
> > on the command trigger tuple. But then again just about nothing else
> > does :(
>
> As you say, about nothing else does. I think that's a work for another
> patch.
Not sure, that way the required work is getting bigger and bigger. But I can
live with that... I think the command trigger work will make better
concurrency safeness of DDL necessary.
> > 2. the switch to cmd->oldmctx made me very wary at first because I wasn't
> > sure its guaranteed to be non NULL
> >
> > - why is there a special CommandTriggerContext if its not reset
> > separately? Should it be reset? I have to say that I dislike the api
> > around this.
>
> Some call sites need to be able to call those functions a dynamic number
> of times. I could add a reset boolean parameter that would mostly be
> true in all call site and false in two of them (RemoveObjects,
> RemoveRelations), and add a new function to just reset the memory
> context then.
> Or maybe you have a better idea about the ideal API here?
I wonder if the answer is making the API more symmetric. Seems more future-
proof in combination to being cleaner.
//create a new memory context
InitCommandContext(cmd);
if(CommandFiresTriggers(cmd)){
//still in current memory context, after all not much memory should be
allocated here
cmd.foo = bar;
//switches memory context during function execution, resets it afterwards
ExecBeforeCommandTriggers(cmd);
}
if(CommandFiresTriggers(cmd)){
cmd.zap = blub;
ExecAfterCommandTriggers(cmd);
}
//drop the memory context
CleanupCommandContext(cmd);
I find the changing of memory context in CommandFires[After]Trigger + switch
back in Exec*CommandTrigger rather bad style and I don't really see the point
anyway.
> > - an AFTER .. ALTER AGGREATE ... SET SCHEMA has the wrong schema.
> > Probably the same problem exists elsewhere. Or is that as-designed?
> > Would be inconsistent with the way object names are handled.
>
> I'm surprised, here's an excerpt from the added regression tests:
>
> alter function notfun(int) set schema cmd;
> NOTICE: snitch: BEFORE any ALTER FUNCTION
> NOTICE: snitch: BEFORE ALTER FUNCTION public notfun
> NOTICE: snitch: AFTER ALTER FUNCTION cmd notfun
> NOTICE: snitch: AFTER any ALTER FUNCTION
I was not looking at ALTER FUNCTION but ALTER AGGREGATE. And I looked wrongly.
Sorry for that.
Generally, uppon rereading, I have to say that I am not very happy with the
decision that ANY triggers are fired from other places than the specific
triggers. That seams to be a rather dangerous/confusing route to me.
Especially because sometimes errors (permissions, duplicated names, etc) are
raised differently in ANY than in specific triggers now:
postgres=# ALTER AGGREGATE bar.array_agg_union3(anyarray) SET SCHEMA public;
NOTICE: when BEFORE, tag ALTER AGGREGATE, objectid <NULL>, schemaname <NULL>,
objectname <NULL>
ERROR: aggregate bar.array_agg_union3(anyarray) does not exist
postgres=# ALTER AGGREGATE public.array_agg_union3(anyarray) SET SCHEMA
public;
NOTICE: when BEFORE, tag ALTER AGGREGATE, objectid <NULL>, schemaname <NULL>,
objectname <NULL>
ERROR: function array_agg_union3(anyarray) is already in schema "public"
postgres=# ALTER AGGREGATE public.array_agg_union3(anyarray) SET SCHEMA bar;
NOTICE: when BEFORE, tag ALTER AGGREGATE, objectid <NULL>, schemaname <NULL>,
objectname <NULL>
NOTICE: when BEFORE, tag ALTER AGGREGATE, objectid 16415, schemaname public,
objectname array_agg_union3
NOTICE: when AFTER, tag ALTER AGGREGATE, objectid 16415, schemaname bar,
objectname array_agg_union3
NOTICE: when AFTER, tag ALTER AGGREGATE, objectid <NULL>, schemaname <NULL>,
objectname <NULL>
Andres
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
@ 2012-03-14 03:41 ` Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-14 03:41 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund <andres@anarazel.de> wrote:
> Generally, uppon rereading, I have to say that I am not very happy with the
> decision that ANY triggers are fired from other places than the specific
> triggers. That seams to be a rather dangerous/confusing route to me.
I agree. I think that's a complete non-starter.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-14 08:27 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-14 12:56 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-14 08:27 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Andres Freund <andres@anarazel.de>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 13, 2012 at 5:06 PM, Andres Freund <andres@anarazel.de> wrote:
>> Generally, uppon rereading, I have to say that I am not very happy with the
>> decision that ANY triggers are fired from other places than the specific
>> triggers. That seams to be a rather dangerous/confusing route to me.
>
> I agree. I think that's a complete non-starter.
Ok, well, let me react in 2 ways here:
A. it's very easy to change and will simplify the code
B. it's been done this way for good reasons (at the time)
Specifically, I've been asked to implement the feature of blocking all
and any DDL activity on a machine in a single command, and we don't have
support for triggers on all commands (remember shared objects).
Now, as I've completed support for all interesting commands the
discrepancy between what's supported in the ANY case and in the specific
command case has reduced. If you're saying to nothing, that's good news.
Also, when calling the user's procedure from the same place in case of an
ANY command trigger or a specific one it's then possible to just hand
them over the exact same set of info (object id, name, schema name).
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-14 12:56 ` Robert Haas <robertmhaas@gmail.com>
2012-03-14 21:33 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Robert Haas @ 2012-03-14 12:56 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers
On Wed, Mar 14, 2012 at 4:27 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Also, when calling the user's procedure from the same place in case of an
> ANY command trigger or a specific one it's then possible to just hand
> them over the exact same set of info (object id, name, schema name).
Yes, I think that's an essential property of the system, here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-14 12:56 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
@ 2012-03-14 21:33 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-15 12:03 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
0 siblings, 1 reply; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-14 21:33 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; Andres Freund <andres@anarazel.de>; pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>> Also, when calling the user's procedure from the same place in case of an
>> ANY command trigger or a specific one it's then possible to just hand
>> them over the exact same set of info (object id, name, schema name).
>
> Yes, I think that's an essential property of the system, here.
Ok, I've implemented that. No patch attached because I need to merge
with master again and I'm out to sleep now, it sometimes ring when being
on-call…
Curious people might have a look at my github repository where the
command_triggers branch is updated:
https://github.com/dimitri/postgres/compare/daf69e1e...e3714cb9e6
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-14 12:56 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 21:33 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-15 12:03 ` Thom Brown <thom@linux.com>
2012-03-15 14:52 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 1 reply; 115+ messages in thread
From: Thom Brown @ 2012-03-15 12:03 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; pgsql-hackers
On 14 March 2012 21:33, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Ok, I've implemented that. No patch attached because I need to merge
> with master again and I'm out to sleep now, it sometimes ring when being
> on-call…
>
> Curious people might have a look at my github repository where the
> command_triggers branch is updated:
Will you also be committing the trigger function variable changes
shortly? I don't wish to test anything prior to this as that will
involve a complete re-test from my side anyway.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 11:22 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-13 20:07 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Re: Command Triggers, patch v11 Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-14 12:56 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
2012-03-14 21:33 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-15 12:03 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
@ 2012-03-15 14:52 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 0 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-15 14:52 UTC (permalink / raw)
To: Thom Brown <thom@linux.com>; +Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>; Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; pgsql-hackers
Thom Brown <thom@linux.com> writes:
> Will you also be committing the trigger function variable changes
> shortly? I don't wish to test anything prior to this as that will
> involve a complete re-test from my side anyway.
It's on its way, I had to spend time elsewhere, sorry about that. With
some luck I can post a intermediate patch later this evening limited to
PLpgSQL support for your testing.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
@ 2012-03-03 16:12 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 16:21 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-03 19:25 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
0 siblings, 2 replies; 115+ messages in thread
From: Kevin Grittner @ 2012-03-03 16:12 UTC (permalink / raw)
To: dimitri@2ndquadrant.fr; thom@linux.com; +Cc: robertmhaas@gmail.com; pgsql-hackers; tgl@sss.pgh.pa.us
> Thom Brown wrote:
> Dimitri Fontaine wrote:
>> Thom Brown writes:
>>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>>> comment, as it makes more sense to drop the entire trigger than
>>> individual commands for that trigger.
>>
>> What you're saying here is that a single command could have more
>> than one command attached to it, and what I understand Tom, Robert
>> and Kevin are saying is that any given command trigger should only
>> be attached to a single command.
>
> I hadn't interpreted it that way
Nor had I.
> I'm still of the opinion that a single command trigger should be
able to attach to multiple commands, just not
> amendable once the trigger has been created.
That was my understanding of what we were discussing, too.
> So my vote was for:
>
> CREATE COMMAND TRIGGER name { BEFORE | AFTER } command [, ... ]
> EXECUTE PROCEDURE function_name ()
>
> ALTER COMMAND TRIGGER name SET enabled
>
> DROP COMMAND TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]
Same here.
> My argument for this is that you may wish to implement the same
> trigger for tables, views and foreign tables rather than create 3
> separate triggers.
Right. What I thought I was agreeing with was the notion that you
should need to specify more than the trigger name to drop the
trigger. Rather like how you can create a trigger AFTER INSERT OR
UPDATE OR DELETE, but you don't need to specify all those events to
drop the trigger -- just the name will do.
-Kevin
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-03-03 16:12 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
@ 2012-03-03 16:21 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-03 16:21 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: dimitri@2ndquadrant.fr; robertmhaas@gmail.com; pgsql-hackers; tgl@sss.pgh.pa.us
On 3 March 2012 16:12, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
>> Thom Brown wrote:
>> Dimitri Fontaine wrote:
>>> Thom Brown writes:
>>>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>>>> comment, as it makes more sense to drop the entire trigger than
>>>> individual commands for that trigger.
>>>
>>> What you're saying here is that a single command could have more
>>> than one command attached to it, and what I understand Tom, Robert
>>> and Kevin are saying is that any given command trigger should only
>>> be attached to a single command.
>>
>> I hadn't interpreted it that way
>
> Nor had I.
>
>> I'm still of the opinion that a single command trigger should be
> able to attach to multiple commands, just not
>> amendable once the trigger has been created.
>
> That was my understanding of what we were discussing, too.
>
>> So my vote was for:
>>
>> CREATE COMMAND TRIGGER name { BEFORE | AFTER } command [, ... ]
>> EXECUTE PROCEDURE function_name ()
>>
>> ALTER COMMAND TRIGGER name SET enabled
>>
>> DROP COMMAND TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]
>
> Same here.
>
>> My argument for this is that you may wish to implement the same
>> trigger for tables, views and foreign tables rather than create 3
>> separate triggers.
>
> Right. What I thought I was agreeing with was the notion that you
> should need to specify more than the trigger name to drop the
> trigger. Rather like how you can create a trigger AFTER INSERT OR
> UPDATE OR DELETE, but you don't need to specify all those events to
> drop the trigger -- just the name will do.
Don't you mean "shouldn't need to specify more than the trigger name"?
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-03-03 16:12 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
@ 2012-03-03 19:25 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 19:47 ` Re: Command Triggers, patch v11 Thom Brown <thom@linux.com>
2012-03-05 21:17 ` Re: Command Triggers, patch v11 Robert Haas <robertmhaas@gmail.com>
1 sibling, 2 replies; 115+ messages in thread
From: Dimitri Fontaine @ 2012-03-03 19:25 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: dimitri@2ndquadrant.fr; thom@linux.com; robertmhaas@gmail.com; pgsql-hackers; tgl@sss.pgh.pa.us
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Right. What I thought I was agreeing with was the notion that you
> should need to specify more than the trigger name to drop the
> trigger. Rather like how you can create a trigger AFTER INSERT OR
> UPDATE OR DELETE, but you don't need to specify all those events to
> drop the trigger -- just the name will do.
The parallel between INSERT/UPDATE/DELETE and the trigger's command is
not working well enough, because in the data trigger case we're managing
a single catalog entry with a single command, and in the command trigger
case, in my model at least, we would be managing several catalog entries
per command.
To take an example:
CREATE COMMAND TRIGGER foo AFTER create table, create view;
DROP COMMAND TRIGGER foo;
The first command would create two catalog entries, and the second one
would delete the same two entries. It used to work this way in the
patch, then when merging with the new remove object infrastructure I
lost that ability. From the beginning Robert has been saying he didn't
want that behavior, and Tom is now saying the same, IIUC.
So we're back to one command, one catalog entry.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-03-03 16:12 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 19:25 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-03 19:47 ` Thom Brown <thom@linux.com>
1 sibling, 0 replies; 115+ messages in thread
From: Thom Brown @ 2012-03-03 19:47 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; robertmhaas@gmail.com; pgsql-hackers; tgl@sss.pgh.pa.us
On 3 March 2012 19:25, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Right. What I thought I was agreeing with was the notion that you
>> should need to specify more than the trigger name to drop the
>> trigger. Rather like how you can create a trigger AFTER INSERT OR
>> UPDATE OR DELETE, but you don't need to specify all those events to
>> drop the trigger -- just the name will do.
>
> The parallel between INSERT/UPDATE/DELETE and the trigger's command is
> not working well enough, because in the data trigger case we're managing
> a single catalog entry with a single command, and in the command trigger
> case, in my model at least, we would be managing several catalog entries
> per command.
>
> To take an example:
>
> CREATE COMMAND TRIGGER foo AFTER create table, create view;
> DROP COMMAND TRIGGER foo;
>
> The first command would create two catalog entries, and the second one
> would delete the same two entries. It used to work this way in the
> patch, then when merging with the new remove object infrastructure I
> lost that ability. From the beginning Robert has been saying he didn't
> want that behavior, and Tom is now saying the same, IIUC.
>
> So we're back to one command, one catalog entry.
That sucks. I'm surprised there's no provision for overriding it on a
command-by-command basis.
I would suggest an array instead, but that sounds costly from a
look-up perspective.
--
Thom
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
2012-03-03 16:12 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 19:25 ` Re: Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
@ 2012-03-05 21:17 ` Robert Haas <robertmhaas@gmail.com>
1 sibling, 0 replies; 115+ messages in thread
From: Robert Haas @ 2012-03-05 21:17 UTC (permalink / raw)
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; thom@linux.com; pgsql-hackers; tgl@sss.pgh.pa.us
On Sat, Mar 3, 2012 at 2:25 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Right. What I thought I was agreeing with was the notion that you
>> should need to specify more than the trigger name to drop the
>> trigger. Rather like how you can create a trigger AFTER INSERT OR
>> UPDATE OR DELETE, but you don't need to specify all those events to
>> drop the trigger -- just the name will do.
>
> The parallel between INSERT/UPDATE/DELETE and the trigger's command is
> not working well enough, because in the data trigger case we're managing
> a single catalog entry with a single command, and in the command trigger
> case, in my model at least, we would be managing several catalog entries
> per command.
>
> To take an example:
>
> CREATE COMMAND TRIGGER foo AFTER create table, create view;
> DROP COMMAND TRIGGER foo;
>
> The first command would create two catalog entries, and the second one
> would delete the same two entries. It used to work this way in the
> patch, then when merging with the new remove object infrastructure I
> lost that ability. From the beginning Robert has been saying he didn't
> want that behavior, and Tom is now saying the same, IIUC.
>
> So we're back to one command, one catalog entry.
I hadn't made the connection here until you read this, but I agree
there's a problem there. One command, one catalog entry is, I think,
pretty important. So that means that if want to support a trigger on
CREATE TABLE OR CREATE VIEW OR DROP EXTENSION, then the command names
(or integers that serve as proxies for them) need to go into an array
somewhere, and we had to look for arrays that contain the command
we're looking for, rather than just the command name. That might seem
prohibitively slow, but I bet if you put a proper cache in place it
isn't, because pg_cmdtrigger should be pretty small and not updated
very often. You can probably afford to seq-scan it and rebuild your
entire cache across all command types every time it changes in any
way.
But just supporting one command type per trigger seems fine for a
first version, too. There's nothing to prevent us from adding that
later.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 115+ messages in thread
* Re: Command Triggers, patch v11
@ 2012-03-03 18:37 Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 0 replies; 115+ messages in thread
From: Kevin Grittner @ 2012-03-03 18:37 UTC (permalink / raw)
To: thom@linux.com; +Cc: dimitri@2ndquadrant.fr; robertmhaas@gmail.com; pgsql-hackers; tgl@sss.pgh.pa.us
Thom Brown wrote:
> Don't you mean "shouldn't need to specify more than the trigger
> name"?
You are right, that's what I meant to say.
-Kevin
^ permalink raw reply [nested|flat] 115+ messages in thread
end of thread, other threads:[~2012-03-20 17:44 UTC | newest]
Thread overview: 115+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-02-24 22:04 Command Triggers, patch v11 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-24 22:32 ` Thom Brown <thom@linux.com>
2012-02-24 22:39 ` Thom Brown <thom@linux.com>
2012-02-24 23:01 ` Thom Brown <thom@linux.com>
2012-02-24 23:43 ` Thom Brown <thom@linux.com>
2012-02-25 11:58 ` Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-28 11:43 ` Thom Brown <thom@linux.com>
2012-02-28 13:32 ` Thom Brown <thom@linux.com>
2012-02-28 15:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 15:09 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 00:12 ` Robert Haas <robertmhaas@gmail.com>
2012-03-03 13:45 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 14:03 ` Thom Brown <thom@linux.com>
2012-03-03 14:34 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 15:55 ` Thom Brown <thom@linux.com>
2012-02-28 15:14 ` Thom Brown <thom@linux.com>
2012-03-02 22:32 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-02 23:33 ` Thom Brown <thom@linux.com>
2012-03-03 00:08 ` Thom Brown <thom@linux.com>
2012-03-03 00:39 ` anarazel@anarazel.de <andres@anarazel.de>
2012-03-03 00:56 ` Thom Brown <thom@linux.com>
2012-03-03 14:26 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 15:37 ` Thom Brown <thom@linux.com>
2012-03-04 15:50 ` Andres Freund <andres@anarazel.de>
2012-03-05 00:33 ` Thom Brown <thom@linux.com>
2012-03-05 20:42 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-05 21:10 ` Andres Freund <andres@anarazel.de>
2012-03-05 21:33 ` Thom Brown <thom@linux.com>
2012-03-06 21:04 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-06 21:18 ` Thom Brown <thom@linux.com>
2012-03-06 23:25 ` Thom Brown <thom@linux.com>
2012-03-07 21:53 ` Thom Brown <thom@linux.com>
2012-03-09 14:09 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:22 ` Thom Brown <thom@linux.com>
2012-03-09 14:30 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 14:35 ` Thom Brown <thom@linux.com>
2012-03-09 14:47 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 15:02 ` Thom Brown <thom@linux.com>
2012-03-09 17:51 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 19:16 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 15:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-09 15:09 ` Thom Brown <thom@linux.com>
2012-03-09 15:29 ` Robert Haas <robertmhaas@gmail.com>
2012-03-09 17:29 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-08 22:24 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 00:28 ` Thom Brown <thom@linux.com>
2012-03-09 11:53 ` Thom Brown <thom@linux.com>
2012-03-09 21:38 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-09 22:42 ` Thom Brown <thom@linux.com>
2012-03-16 20:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:07 ` Andres Freund <andres@anarazel.de>
2012-03-16 21:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 21:37 ` Andres Freund <andres@anarazel.de>
2012-03-16 21:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-16 22:17 ` Andres Freund <andres@anarazel.de>
2012-03-17 15:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 17:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 18:16 ` Andres Freund <andres@anarazel.de>
2012-03-17 22:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-17 22:26 ` Andres Freund <andres@anarazel.de>
2012-03-18 18:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-18 19:12 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-19 01:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 13:13 ` Andres Freund <andres@anarazel.de>
2012-03-19 16:35 ` Robert Haas <robertmhaas@gmail.com>
2012-03-19 16:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:52 ` Robert Haas <robertmhaas@gmail.com>
2012-03-18 21:47 ` Peter Eisentraut <peter_e@gmx.net>
2012-03-19 01:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 16:53 ` Peter Eisentraut <peter_e@gmx.net>
2012-03-19 17:06 ` Robert Haas <robertmhaas@gmail.com>
2012-03-19 18:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-19 18:51 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 01:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-03-20 15:55 ` Andres Freund <andres@anarazel.de>
2012-03-20 17:44 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:00 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-25 12:07 ` Thom Brown <thom@linux.com>
2012-02-25 12:42 ` Thom Brown <thom@linux.com>
2012-02-25 13:15 ` Thom Brown <thom@linux.com>
2012-02-25 13:28 ` Thom Brown <thom@linux.com>
2012-02-25 14:30 ` Thom Brown <thom@linux.com>
2012-02-25 16:36 ` Thom Brown <thom@linux.com>
2012-02-26 00:07 ` Thom Brown <thom@linux.com>
2012-02-26 14:12 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-26 19:49 ` Thom Brown <thom@linux.com>
2012-02-26 23:24 ` Thom Brown <thom@linux.com>
2012-02-27 19:31 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 20:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-27 21:22 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-04 18:08 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:19 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:19 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-02-27 19:30 ` Thom Brown <thom@linux.com>
2012-02-27 19:37 ` Andres Freund <andres@anarazel.de>
2012-02-27 23:32 ` Andres Freund <andres@anarazel.de>
2012-02-28 00:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-02-28 00:29 ` anarazel@anarazel.de <andres@anarazel.de>
2012-03-13 11:22 ` Andres Freund <andres@anarazel.de>
2012-03-13 15:14 ` Alvaro Herrera <alvherre@commandprompt.com>
2012-03-13 20:07 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-13 21:06 ` Andres Freund <andres@anarazel.de>
2012-03-14 03:41 ` Robert Haas <robertmhaas@gmail.com>
2012-03-14 08:27 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-14 12:56 ` Robert Haas <robertmhaas@gmail.com>
2012-03-14 21:33 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-15 12:03 ` Thom Brown <thom@linux.com>
2012-03-15 14:52 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 16:12 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
2012-03-03 16:21 ` Thom Brown <thom@linux.com>
2012-03-03 19:25 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2012-03-03 19:47 ` Thom Brown <thom@linux.com>
2012-03-05 21:17 ` Robert Haas <robertmhaas@gmail.com>
2012-03-03 18:37 Re: Command Triggers, patch v11 Kevin Grittner <Kevin.Grittner@wicourts.gov>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox