rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/test/modules/test_ddl_deparse/test_ddl_deparse.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

342 lines
7.9 KiB
C
Raw Normal View History

Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
/*----------------------------------------------------------------------
* test_ddl_deparse.c
* Support functions for the test_ddl_deparse module
*
Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12
2024-01-04 02:49:05 +01:00
* Copyright (c) 2014-2024, PostgreSQL Global Development Group
Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
*
* IDENTIFICATION
* src/test/modules/test_ddl_deparse/test_ddl_deparse.c
*----------------------------------------------------------------------
*/
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
#include "postgres.h"
#include "catalog/pg_type.h"
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
#include "funcapi.h"
#include "nodes/execnodes.h"
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
#include "tcop/deparse_utility.h"
#include "tcop/utility.h"
#include "utils/builtins.h"
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(get_command_type);
PG_FUNCTION_INFO_V1(get_command_tag);
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
PG_FUNCTION_INFO_V1(get_altertable_subcmdinfo);
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
/*
* Return the textual representation of the struct type used to represent a
* command in struct CollectedCommand format.
*/
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Datum
get_command_type(PG_FUNCTION_ARGS)
{
CollectedCommand *cmd = (CollectedCommand *) PG_GETARG_POINTER(0);
const char *type;
switch (cmd->type)
{
case SCT_Simple:
type = "simple";
break;
case SCT_AlterTable:
type = "alter table";
break;
case SCT_Grant:
type = "grant";
break;
case SCT_AlterOpFamily:
type = "alter operator family";
break;
case SCT_AlterDefaultPrivileges:
type = "alter default privileges";
break;
case SCT_CreateOpClass:
type = "create operator class";
break;
case SCT_AlterTSConfig:
type = "alter text search configuration";
break;
default:
type = "unknown command type";
break;
}
PG_RETURN_TEXT_P(cstring_to_text(type));
}
Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
/*
* Return the command tag corresponding to a parse node contained in a
* CollectedCommand struct.
*/
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Datum
get_command_tag(PG_FUNCTION_ARGS)
{
CollectedCommand *cmd = (CollectedCommand *) PG_GETARG_POINTER(0);
if (!cmd->parsetree)
PG_RETURN_NULL();
Represent command completion tags as structs The backend was using strings to represent command tags and doing string comparisons in multiple places, but that's slow and unhelpful. Create a new command list with a supporting structure to use instead; this is stored in a tag-list-file that can be tailored to specific purposes with a caller-definable C macro, similar to what we do for WAL resource managers. The first first such uses are a new CommandTag enum and a CommandTagBehavior struct. Replace numerous occurrences of char *completionTag with a QueryCompletion struct so that the code no longer stores information about completed queries in a cstring. Only at the last moment, in EndCommand(), does this get converted to a string. EventTriggerCacheItem no longer holds an array of palloc’d tag strings in sorted order, but rather just a Bitmapset over the CommandTags. Author: Mark Dilger, with unsolicited help from Álvaro Herrera Reviewed-by: John Naylor, Tom Lane Discussion: https://postgr.es/m/981A9DB4-3F0C-4DA5-88AD-CB9CFF4D6CAD@enterprisedb.com
2020-03-02 22:19:51 +01:00
PG_RETURN_TEXT_P(cstring_to_text(CreateCommandName(cmd->parsetree)));
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
}
Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
/*
* Return a text array representation of the subcommands of an ALTER TABLE
* command.
*/
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Datum
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
get_altertable_subcmdinfo(PG_FUNCTION_ARGS)
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
{
CollectedCommand *cmd = (CollectedCommand *) PG_GETARG_POINTER(0);
ListCell *cell;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
if (cmd->type != SCT_AlterTable)
elog(ERROR, "command is not ALTER TABLE");
Rename SetSingleFuncCall() to InitMaterializedSRF() Per discussion, the existing routine name able to initialize a SRF function with materialize mode is unpopular, so rename it. Equally, the flags of this function are renamed, as of: - SRF_SINGLE_USE_EXPECTED -> MAT_SRF_USE_EXPECTED_DESC - SRF_SINGLE_BLESS -> MAT_SRF_BLESS The previous function and flags introduced in 9e98583 are kept around for compatibility purposes, so as any extension code already compiled with v15 continues to work as-is. The declarations introduced here for compatibility will be removed from HEAD in a follow-up commit. The new names have been suggested by Andres Freund and Melanie Plageman. Discussion: https://postgr.es/m/20221013194820.ciktb2sbbpw7cljm@awork3.anarazel.de Backpatch-through: 15
2022-10-18 03:22:35 +02:00
InitMaterializedSRF(fcinfo, 0);
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
Avoid using list_length() to test for empty list. The standard way to check for list emptiness is to compare the List pointer to NIL; our list code goes out of its way to ensure that that is the only representation of an empty list. (An acceptable alternative is a plain boolean test for non-null pointer, but explicit mention of NIL is usually preferable.) Various places didn't get that memo and expressed the condition with list_length(), which might not be so bad except that there were such a variety of ways to check it exactly: equal to zero, less than or equal to zero, less than one, yadda yadda. In the name of code readability, let's standardize all those spellings as "list == NIL" or "list != NIL". (There's probably some microscopic efficiency gain too, though few of these look to be at all performance-critical.) A very small number of cases were left as-is because they seemed more consistent with other adjacent list_length tests that way. Peter Smith, with bikeshedding from a number of us Discussion: https://postgr.es/m/CAHut+PtQYe+ENX5KrONMfugf0q6NHg4hR5dAhqEXEc2eefFeig@mail.gmail.com
2022-08-17 17:12:35 +02:00
if (cmd->d.alterTable.subcmds == NIL)
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
elog(ERROR, "empty alter table subcommand list");
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
foreach(cell, cmd->d.alterTable.subcmds)
{
CollectedATSubcmd *sub = lfirst(cell);
Make more use of castNode()
2017-02-21 17:33:07 +01:00
AlterTableCmd *subcmd = castNode(AlterTableCmd, sub->parsetree);
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
const char *strtype = "unrecognized";
Datum values[2];
bool nulls[2];
memset(values, 0, sizeof(values));
memset(nulls, 0, sizeof(nulls));
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
switch (subcmd->subtype)
{
case AT_AddColumn:
strtype = "ADD COLUMN";
break;
case AT_AddColumnToView:
strtype = "ADD COLUMN TO VIEW";
break;
case AT_ColumnDefault:
strtype = "ALTER COLUMN SET DEFAULT";
break;
Fix handling of CREATE TABLE LIKE with inheritance. If a CREATE TABLE command uses both LIKE and traditional inheritance, Vars in CHECK constraints and expression indexes that are absorbed from a LIKE parent table tended to get mis-numbered, resulting in wrong answers and/or bizarre error messages (though probably not any actual crashes, thanks to validation occurring in the executor). In v12 and up, the same could happen to Vars in GENERATED expressions, even in cases with no LIKE clause but multiple traditional-inheritance parents. The cause of the problem for LIKE is that parse_utilcmd.c supposed it could renumber such Vars correctly during transformCreateStmt(), which it cannot since we have not yet accounted for columns added via inheritance. Fix that by postponing processing of LIKE INCLUDING CONSTRAINTS, DEFAULTS, GENERATED, INDEXES till after we've performed DefineRelation(). The error with GENERATED and multiple inheritance is a simple oversight in MergeAttributes(); it knows it has to renumber Vars in inherited CHECK constraints, but forgot to apply the same processing to inherited GENERATED expressions (a/k/a defaults). Per bug #16272 from Tom Gottfried. The non-GENERATED variants of the issue are ancient, presumably dating right back to the addition of CREATE TABLE LIKE; hence back-patch to all supported branches. Discussion: https://postgr.es/m/16272-6e32da020e9a9381@postgresql.org
2020-08-21 21:00:42 +02:00
case AT_CookedColumnDefault:
strtype = "ALTER COLUMN SET DEFAULT (precooked)";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_DropNotNull:
strtype = "DROP NOT NULL";
break;
case AT_SetNotNull:
strtype = "SET NOT NULL";
break;
Catalog not-null constraints We now create contype='n' pg_constraint rows for not-null constraints. We propagate these constraints to other tables during operations such as adding inheritance relationships, creating and attaching partitions and creating tables LIKE other tables. We also spawn not-null constraints for inheritance child tables when their parents have primary keys. These related constraints mostly follow the well-known rules of conislocal and coninhcount that we have for CHECK constraints, with some adaptations: for example, as opposed to CHECK constraints, we don't match not-null ones by name when descending a hierarchy to alter it, instead matching by column name that they apply to. This means we don't require the constraint names to be identical across a hierarchy. For now, we omit them for system catalogs. Maybe this is worth reconsidering. We don't support NOT VALID nor DEFERRABLE clauses either; these can be added as separate features later (this patch is already large and complicated enough.) psql shows these constraints in \d+. pg_dump requires some ad-hoc hacks, particularly when dumping a primary key. We now create one "throwaway" not-null constraint for each column in the PK together with the CREATE TABLE command, and once the PK is created, all those throwaway constraints are removed. This avoids having to check each tuple for nullness when the dump restores the primary key creation. pg_upgrading from an older release requires a somewhat brittle procedure to create a constraint state that matches what would be created if the database were being created fresh in Postgres 17. I have tested all the scenarios I could think of, and it works correctly as far as I can tell, but I could have neglected weird cases. This patch has been very long in the making. The first patch was written by Bernd Helmle in 2010 to add a new pg_constraint.contype value ('n'), which I (Álvaro) then hijacked in 2011 and 2012, until that one was killed by the realization that we ought to use contype='c' instead: manufactured CHECK constraints. However, later SQL standard development, as well as nonobvious emergent properties of that design (mostly, failure to distinguish them from "normal" CHECK constraints as well as the performance implication of having to test the CHECK expression) led us to reconsider this choice, so now the current implementation uses contype='n' again. During Postgres 16 this had already been introduced by commit e056c557aef4, but there were some problems mainly with the pg_upgrade procedure that couldn't be fixed in reasonable time, so it was reverted. In 2016 Vitaly Burovoy also worked on this feature[1] but found no consensus for his proposed approach, which was claimed to be closer to the letter of the standard, requiring an additional pg_attribute column to track the OID of the not-null constraint for that column. [1] https://postgr.es/m/CAKOSWNkN6HSyatuys8xZxzRCR-KL1OkHS5-b9qd9bf1Rad3PLA@mail.gmail.com Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Author: Bernd Helmle <mailings@oopsware.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com>
2023-08-25 13:31:24 +02:00
case AT_SetAttNotNull:
strtype = "SET ATTNOTNULL";
break;
ALTER TABLE command to change generation expression This adds a new ALTER TABLE subcommand ALTER COLUMN ... SET EXPRESSION that changes the generation expression of a generated column. The syntax is not standard but was adapted from other SQL implementations. This command causes a table rewrite, using the usual ALTER TABLE mechanisms. The implementation is similar to and makes use of some of the infrastructure of the SET DATA TYPE subcommand (for example, rebuilding constraints and indexes afterwards). The new command requires a new pass in AlterTablePass, and the ADD COLUMN pass had to be moved earlier so that combinations of ADD COLUMN and SET EXPRESSION can work. Author: Amul Sul <sulamul@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAAJ_b94yyJeGA-5M951_Lr+KfZokOp-2kXicpmEhi5FXhBeTog@mail.gmail.com
2024-01-04 15:45:35 +01:00
case AT_SetExpression:
strtype = "SET EXPRESSION";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_DropExpression:
strtype = "DROP EXPRESSION";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_SetStatistics:
strtype = "SET STATS";
break;
case AT_SetOptions:
strtype = "SET OPTIONS";
break;
case AT_ResetOptions:
strtype = "RESET OPTIONS";
break;
case AT_SetStorage:
strtype = "SET STORAGE";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_SetCompression:
strtype = "SET COMPRESSION";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_DropColumn:
strtype = "DROP COLUMN";
break;
case AT_AddIndex:
strtype = "ADD INDEX";
break;
case AT_ReAddIndex:
strtype = "(re) ADD INDEX";
break;
case AT_AddConstraint:
strtype = "ADD CONSTRAINT";
break;
case AT_ReAddConstraint:
strtype = "(re) ADD CONSTRAINT";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_ReAddDomainConstraint:
strtype = "(re) ADD DOMAIN CONSTRAINT";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_AlterConstraint:
strtype = "ALTER CONSTRAINT";
break;
case AT_ValidateConstraint:
strtype = "VALIDATE CONSTRAINT";
break;
case AT_AddIndexConstraint:
strtype = "ADD CONSTRAINT (using index)";
break;
case AT_DropConstraint:
strtype = "DROP CONSTRAINT";
break;
Handle AT_ReAddComment in test_ddl_deparse, and add a catch-all default. In the passing, also move AT_ReAddComment to more logical position in the enum, after all the Constraint-related subcommands. This fixes a compiler warning, added by commit e42375fc. Backpatch to 9.5, like that patch.
2015-07-20 09:19:22 +02:00
case AT_ReAddComment:
strtype = "(re) ADD COMMENT";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_AlterColumnType:
strtype = "ALTER COLUMN SET TYPE";
break;
case AT_AlterColumnGenericOptions:
strtype = "ALTER COLUMN SET OPTIONS";
break;
case AT_ChangeOwner:
strtype = "CHANGE OWNER";
break;
case AT_ClusterOn:
strtype = "CLUSTER";
break;
case AT_DropCluster:
strtype = "DROP CLUSTER";
break;
case AT_SetLogged:
strtype = "SET LOGGED";
break;
case AT_SetUnLogged:
strtype = "SET UNLOGGED";
break;
case AT_DropOids:
strtype = "DROP OIDS";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_SetAccessMethod:
strtype = "SET ACCESS METHOD";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_SetTableSpace:
strtype = "SET TABLESPACE";
break;
case AT_SetRelOptions:
strtype = "SET RELOPTIONS";
break;
case AT_ResetRelOptions:
strtype = "RESET RELOPTIONS";
break;
case AT_ReplaceRelOptions:
strtype = "REPLACE RELOPTIONS";
break;
case AT_EnableTrig:
strtype = "ENABLE TRIGGER";
break;
case AT_EnableAlwaysTrig:
strtype = "ENABLE TRIGGER (always)";
break;
case AT_EnableReplicaTrig:
strtype = "ENABLE TRIGGER (replica)";
break;
case AT_DisableTrig:
strtype = "DISABLE TRIGGER";
break;
case AT_EnableTrigAll:
strtype = "ENABLE TRIGGER (all)";
break;
case AT_DisableTrigAll:
strtype = "DISABLE TRIGGER (all)";
break;
case AT_EnableTrigUser:
strtype = "ENABLE TRIGGER (user)";
break;
case AT_DisableTrigUser:
strtype = "DISABLE TRIGGER (user)";
break;
case AT_EnableRule:
strtype = "ENABLE RULE";
break;
case AT_EnableAlwaysRule:
strtype = "ENABLE RULE (always)";
break;
case AT_EnableReplicaRule:
strtype = "ENABLE RULE (replica)";
break;
case AT_DisableRule:
strtype = "DISABLE RULE";
break;
case AT_AddInherit:
strtype = "ADD INHERIT";
break;
case AT_DropInherit:
strtype = "DROP INHERIT";
break;
case AT_AddOf:
strtype = "OF";
break;
case AT_DropOf:
strtype = "NOT OF";
break;
case AT_ReplicaIdentity:
strtype = "REPLICA IDENTITY";
break;
case AT_EnableRowSecurity:
strtype = "ENABLE ROW SECURITY";
break;
case AT_DisableRowSecurity:
strtype = "DISABLE ROW SECURITY";
break;
ALTER TABLE .. FORCE ROW LEVEL SECURITY To allow users to force RLS to always be applied, even for table owners, add ALTER TABLE .. FORCE ROW LEVEL SECURITY. row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump output is complete (by default). Also add SECURITY_NOFORCE_RLS context to avoid data corruption when ALTER TABLE .. FORCE ROW SECURITY is being used. The SECURITY_NOFORCE_RLS security context is used only during referential integrity checks and is only considered in check_enable_rls() after we have already checked that the current user is the owner of the relation (which should always be the case during referential integrity checks). Back-patch to 9.5 where RLS was added.
2015-10-05 03:05:08 +02:00
case AT_ForceRowSecurity:
strtype = "FORCE ROW SECURITY";
break;
case AT_NoForceRowSecurity:
strtype = "NO FORCE ROW SECURITY";
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
case AT_GenericOptions:
strtype = "SET OPTIONS";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_DetachPartition:
strtype = "DETACH PARTITION";
break;
case AT_AttachPartition:
strtype = "ATTACH PARTITION";
break;
case AT_DetachPartitionFinalize:
strtype = "DETACH PARTITION ... FINALIZE";
break;
Implement ALTER TABLE ... SPLIT PARTITION ... command This new DDL command splits a single partition into several parititions. Just like ALTER TABLE ... MERGE PARTITIONS ... command, new patitions are created using createPartitionTable() function with parent partition as the template. This commit comprises quite naive implementation which works in single process and holds the ACCESS EXCLUSIVE LOCK on the parent table during all the operations including the tuple routing. This is why this new DDL command can't be recommended for large partitioned tables under a high load. However, this implementation come in handy in certain cases even as is. Also, it could be used as a foundation for future implementations with lesser locking and possibly parallel. Discussion: https://postgr.es/m/c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582%40postgrespro.ru Author: Dmitry Koval Reviewed-by: Matthias van de Meent, Laurenz Albe, Zhihong Yu, Justin Pryzby Reviewed-by: Alvaro Herrera, Robert Haas, Stephane Tachoires
2024-04-06 23:58:09 +02:00
case AT_SplitPartition:
strtype = "SPLIT PARTITION";
break;
Implement ALTER TABLE ... MERGE PARTITIONS ... command This new DDL command merges several partitions into the one partition of the target table. The target partition is created using new createPartitionTable() function with parent partition as the template. This commit comprises quite naive implementation which works in single process and holds the ACCESS EXCLUSIVE LOCK on the parent table during all the operations including the tuple routing. This is why this new DDL command can't be recommended for large partitioned tables under a high load. However, this implementation come in handy in certain cases even as is. Also, it could be used as a foundation for future implementations with lesser locking and possibly parallel. Discussion: https://postgr.es/m/c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582%40postgrespro.ru Author: Dmitry Koval Reviewed-by: Matthias van de Meent, Laurenz Albe, Zhihong Yu, Justin Pryzby Reviewed-by: Alvaro Herrera, Robert Haas, Stephane Tachoires
2024-04-06 23:57:22 +02:00
case AT_MergePartitions:
strtype = "MERGE PARTITIONS";
break;
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
case AT_AddIdentity:
strtype = "ADD IDENTITY";
break;
case AT_SetIdentity:
strtype = "SET IDENTITY";
break;
case AT_DropIdentity:
strtype = "DROP IDENTITY";
break;
case AT_ReAddStatistics:
strtype = "(re) ADD STATS";
Add some comments to test_ddl_deparse and a README Per comments from Heikki Linnakangas. Backpatch to 9.5, where this module was introduced.
2015-07-20 11:20:40 +02:00
break;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
}
Get rid of recursion-marker values in enum AlterTableType During ALTER TABLE execution, when prep-time handling of subcommands of certain types determine that execution-time handling requires recursion, they signal this by changing the subcommand type to a special value. This can be done in a simpler way by using a separate flag introduced by commit ec0925c22a3d, so do that. Catversion bumped. It's not clear to me that ALTER TABLE subcommands are stored anywhere in catalogs (CREATE FUNCTION rejects it in BEGIN ATOMIC function bodies), but we do have both write and read support for them, so be safe. Discussion: https://postgr.es/m/20220929090033.zxuaezcdwh2fgfjb@alvherre.pgsql
2022-12-12 11:13:26 +01:00
if (subcmd->recurse)
values[0] = CStringGetTextDatum(psprintf("%s (and recurse)", strtype));
else
values[0] = CStringGetTextDatum(strtype);
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
if (OidIsValid(sub->address.objectId))
{
char *objdesc;
Pre-beta mechanical code beautification. Run pgindent, pgperltidy, and reformat-dat-files. This set of diffs is a bit larger than typical. We've updated to pg_bsd_indent 2.1.2, which properly indents variable declarations that have multi-line initialization expressions (the continuation lines are now indented one tab stop). We've also updated to perltidy version 20230309 and changed some of its settings, which reduces its desire to add whitespace to lines to make assignments etc. line up. Going forward, that should make for fewer random-seeming changes to existing code. Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql
2023-05-19 23:24:48 +02:00
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
objdesc = getObjectDescription((const ObjectAddress *) &sub->address, false);
values[1] = CStringGetTextDatum(objdesc);
}
else
nulls[1] = true;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc, values, nulls);
}
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
Expand tests of test_ddl_deparse/ for ALTER TABLE This module is expanded to track the description of the objects changed in the subcommands of ALTER TABLE by reworking the function get_altertable_subcmdtypes() (now named get_altertable_subcmdinfo) used in the event trigger of the test. It now returns a set of rows made of (subcommand type, object description) instead of a text array with only the information about the subcommand type. The tests have been lacking a lot of the subcommands added to AlterTableType over the years. All the missing subcommands are added, and the code is now structured so as the addition of a new subcommand is detected by removing the default clause used in the switch for the subcommand types. The coverage of the module is increased from roughly 30% to 50%. More could be done but this is already a nice improvement. Author: Michael Paquier, Hou Zhijie Reviewed-by: Álvaro Herrera, Amit Kapila, Hayato Kuroda Discussion: https://postgr.es/m/OS0PR01MB571626984BD099DADF53F38394899@OS0PR01MB5716.jpnprd01.prod.outlook.com
2022-07-31 04:48:14 +02:00
return (Datum) 0;
Allow on-the-fly capture of DDL event details This feature lets user code inspect and take action on DDL events. Whenever a ddl_command_end event trigger is installed, DDL actions executed are saved to a list which can be inspected during execution of a function attached to ddl_command_end. The set-returning function pg_event_trigger_ddl_commands can be used to list actions so captured; it returns data about the type of command executed, as well as the affected object. This is sufficient for many uses of this feature. For the cases where it is not, we also provide a "command" column of a new pseudo-type pg_ddl_command, which is a pointer to a C structure that can be accessed by C code. The struct contains all the info necessary to completely inspect and even reconstruct the executed command. There is no actual deparse code here; that's expected to come later. What we have is enough infrastructure that the deparsing can be done in an external extension. The intention is that we will add some deparsing code in a later release, as an in-core extension. A new test module is included. It's probably insufficient as is, but it should be sufficient as a starting point for a more complete and future-proof approach. Authors: Álvaro Herrera, with some help from Andres Freund, Ian Barwick, Abhijit Menon-Sen. Reviews by Andres Freund, Robert Haas, Amit Kapila, Michael Paquier, Craig Ringer, David Steele. Additional input from Chris Browne, Dimitri Fontaine, Stephen Frost, Petr Jelínek, Tom Lane, Jim Nasby, Steven Singer, Pavel Stěhule. Based on original work by Dimitri Fontaine, though I didn't use his code. Discussion: https://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr https://www.postgresql.org/message-id/20131108153322.GU5809@eldon.alvh.no-ip.org https://www.postgresql.org/message-id/20150215044814.GL3391@alvh.no-ip.org
2015-05-12 00:14:31 +02:00
}