2017-01-19 18:00:00 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* publicationcmds.c
|
|
|
|
* publication manipulation
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2017-01-25 18:32:05 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
2017-01-19 18:00:00 +01:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* publicationcmds.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2019-12-27 00:09:00 +01:00
|
|
|
#include "access/genam.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "access/htup_details.h"
|
2019-01-21 19:18:20 +01:00
|
|
|
#include "access/table.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "access/xact.h"
|
|
|
|
#include "catalog/catalog.h"
|
|
|
|
#include "catalog/indexing.h"
|
|
|
|
#include "catalog/namespace.h"
|
|
|
|
#include "catalog/objectaccess.h"
|
|
|
|
#include "catalog/objectaddress.h"
|
2020-04-08 09:59:27 +02:00
|
|
|
#include "catalog/partition.h"
|
2018-04-08 20:35:29 +02:00
|
|
|
#include "catalog/pg_inherits.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "catalog/pg_publication.h"
|
|
|
|
#include "catalog/pg_publication_rel.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "catalog/pg_type.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "commands/dbcommands.h"
|
|
|
|
#include "commands/defrem.h"
|
|
|
|
#include "commands/event_trigger.h"
|
|
|
|
#include "commands/publicationcmds.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "funcapi.h"
|
|
|
|
#include "miscadmin.h"
|
2020-03-10 10:22:52 +01:00
|
|
|
#include "utils/acl.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
#include "utils/array.h"
|
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/catcache.h"
|
|
|
|
#include "utils/fmgroids.h"
|
|
|
|
#include "utils/inval.h"
|
|
|
|
#include "utils/lsyscache.h"
|
|
|
|
#include "utils/rel.h"
|
|
|
|
#include "utils/syscache.h"
|
2017-05-12 14:57:01 +02:00
|
|
|
#include "utils/varlena.h"
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Same as MAXNUMMESSAGES in sinvaladt.c */
|
|
|
|
#define MAX_RELCACHE_INVAL_MSGS 4096
|
|
|
|
|
|
|
|
static List *OpenTableList(List *tables);
|
|
|
|
static void CloseTableList(List *rels);
|
|
|
|
static void PublicationAddTables(Oid pubid, List *rels, bool if_not_exists,
|
2019-05-22 19:04:48 +02:00
|
|
|
AlterPublicationStmt *stmt);
|
2017-01-19 18:00:00 +01:00
|
|
|
static void PublicationDropTables(Oid pubid, List *rels, bool missing_ok);
|
|
|
|
|
|
|
|
static void
|
|
|
|
parse_publication_options(List *options,
|
2017-05-12 14:57:01 +02:00
|
|
|
bool *publish_given,
|
2020-04-08 09:59:27 +02:00
|
|
|
PublicationActions *pubactions,
|
|
|
|
bool *publish_via_partition_root_given,
|
|
|
|
bool *publish_via_partition_root)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
ListCell *lc;
|
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
*publish_given = false;
|
2020-04-08 09:59:27 +02:00
|
|
|
*publish_via_partition_root_given = false;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2020-04-08 09:59:27 +02:00
|
|
|
/* defaults */
|
|
|
|
pubactions->pubinsert = true;
|
|
|
|
pubactions->pubupdate = true;
|
|
|
|
pubactions->pubdelete = true;
|
|
|
|
pubactions->pubtruncate = true;
|
|
|
|
*publish_via_partition_root = false;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Parse options */
|
2017-05-17 22:31:56 +02:00
|
|
|
foreach(lc, options)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
DefElem *defel = (DefElem *) lfirst(lc);
|
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
if (strcmp(defel->defname, "publish") == 0)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
2017-05-12 14:57:01 +02:00
|
|
|
char *publish;
|
|
|
|
List *publish_list;
|
|
|
|
ListCell *lc;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
if (*publish_given)
|
2017-01-19 18:00:00 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("conflicting or redundant options")));
|
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
/*
|
|
|
|
* If publish option was given only the explicitly listed actions
|
|
|
|
* should be published.
|
|
|
|
*/
|
2020-04-08 09:59:27 +02:00
|
|
|
pubactions->pubinsert = false;
|
|
|
|
pubactions->pubupdate = false;
|
|
|
|
pubactions->pubdelete = false;
|
|
|
|
pubactions->pubtruncate = false;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
*publish_given = true;
|
|
|
|
publish = defGetString(defel);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
if (!SplitIdentifierString(publish, ',', &publish_list))
|
2017-01-19 18:00:00 +01:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2017-09-11 17:20:47 +02:00
|
|
|
errmsg("invalid list syntax for \"publish\" option")));
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
/* Process the option list. */
|
2017-05-17 22:31:56 +02:00
|
|
|
foreach(lc, publish_list)
|
2017-05-12 14:57:01 +02:00
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
char *publish_opt = (char *) lfirst(lc);
|
2017-05-12 14:57:01 +02:00
|
|
|
|
|
|
|
if (strcmp(publish_opt, "insert") == 0)
|
2020-04-08 09:59:27 +02:00
|
|
|
pubactions->pubinsert = true;
|
2017-05-12 14:57:01 +02:00
|
|
|
else if (strcmp(publish_opt, "update") == 0)
|
2020-04-08 09:59:27 +02:00
|
|
|
pubactions->pubupdate = true;
|
2017-05-12 14:57:01 +02:00
|
|
|
else if (strcmp(publish_opt, "delete") == 0)
|
2020-04-08 09:59:27 +02:00
|
|
|
pubactions->pubdelete = true;
|
2018-04-07 17:24:53 +02:00
|
|
|
else if (strcmp(publish_opt, "truncate") == 0)
|
2020-04-08 09:59:27 +02:00
|
|
|
pubactions->pubtruncate = true;
|
2017-05-12 14:57:01 +02:00
|
|
|
else
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("unrecognized \"publish\" value: \"%s\"", publish_opt)));
|
|
|
|
}
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
2020-04-08 09:59:27 +02:00
|
|
|
else if (strcmp(defel->defname, "publish_via_partition_root") == 0)
|
|
|
|
{
|
|
|
|
if (*publish_via_partition_root_given)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
|
|
|
errmsg("conflicting or redundant options")));
|
|
|
|
*publish_via_partition_root_given = true;
|
|
|
|
*publish_via_partition_root = defGetBoolean(defel);
|
|
|
|
}
|
2017-01-19 18:00:00 +01:00
|
|
|
else
|
2017-05-12 14:57:01 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_SYNTAX_ERROR),
|
2019-05-17 00:50:56 +02:00
|
|
|
errmsg("unrecognized publication parameter: \"%s\"", defel->defname)));
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create new publication.
|
|
|
|
*/
|
|
|
|
ObjectAddress
|
|
|
|
CreatePublication(CreatePublicationStmt *stmt)
|
|
|
|
{
|
|
|
|
Relation rel;
|
|
|
|
ObjectAddress myself;
|
|
|
|
Oid puboid;
|
|
|
|
bool nulls[Natts_pg_publication];
|
|
|
|
Datum values[Natts_pg_publication];
|
|
|
|
HeapTuple tup;
|
2017-05-12 14:57:01 +02:00
|
|
|
bool publish_given;
|
2020-04-08 09:59:27 +02:00
|
|
|
PublicationActions pubactions;
|
|
|
|
bool publish_via_partition_root_given;
|
|
|
|
bool publish_via_partition_root;
|
2017-01-19 18:00:00 +01:00
|
|
|
AclResult aclresult;
|
|
|
|
|
|
|
|
/* must have CREATE privilege on database */
|
|
|
|
aclresult = pg_database_aclcheck(MyDatabaseId, GetUserId(), ACL_CREATE);
|
|
|
|
if (aclresult != ACLCHECK_OK)
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(aclresult, OBJECT_DATABASE,
|
2017-01-19 18:00:00 +01:00
|
|
|
get_database_name(MyDatabaseId));
|
|
|
|
|
|
|
|
/* FOR ALL TABLES requires superuser */
|
|
|
|
if (stmt->for_all_tables && !superuser())
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
2020-01-30 17:32:04 +01:00
|
|
|
errmsg("must be superuser to create FOR ALL TABLES publication")));
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Check if name is used */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
puboid = GetSysCacheOid1(PUBLICATIONNAME, Anum_pg_publication_oid,
|
|
|
|
CStringGetDatum(stmt->pubname));
|
2017-01-19 18:00:00 +01:00
|
|
|
if (OidIsValid(puboid))
|
|
|
|
{
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
errmsg("publication \"%s\" already exists",
|
|
|
|
stmt->pubname)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Form a tuple. */
|
|
|
|
memset(values, 0, sizeof(values));
|
|
|
|
memset(nulls, false, sizeof(nulls));
|
|
|
|
|
|
|
|
values[Anum_pg_publication_pubname - 1] =
|
|
|
|
DirectFunctionCall1(namein, CStringGetDatum(stmt->pubname));
|
|
|
|
values[Anum_pg_publication_pubowner - 1] = ObjectIdGetDatum(GetUserId());
|
|
|
|
|
|
|
|
parse_publication_options(stmt->options,
|
2020-04-08 09:59:27 +02:00
|
|
|
&publish_given, &pubactions,
|
|
|
|
&publish_via_partition_root_given,
|
|
|
|
&publish_via_partition_root);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
puboid = GetNewOidWithIndex(rel, PublicationObjectIndexId,
|
|
|
|
Anum_pg_publication_oid);
|
|
|
|
values[Anum_pg_publication_oid - 1] = ObjectIdGetDatum(puboid);
|
2017-01-19 18:00:00 +01:00
|
|
|
values[Anum_pg_publication_puballtables - 1] =
|
|
|
|
BoolGetDatum(stmt->for_all_tables);
|
|
|
|
values[Anum_pg_publication_pubinsert - 1] =
|
2020-04-08 09:59:27 +02:00
|
|
|
BoolGetDatum(pubactions.pubinsert);
|
2017-01-19 18:00:00 +01:00
|
|
|
values[Anum_pg_publication_pubupdate - 1] =
|
2020-04-08 09:59:27 +02:00
|
|
|
BoolGetDatum(pubactions.pubupdate);
|
2017-01-19 18:00:00 +01:00
|
|
|
values[Anum_pg_publication_pubdelete - 1] =
|
2020-04-08 09:59:27 +02:00
|
|
|
BoolGetDatum(pubactions.pubdelete);
|
2018-04-07 17:24:53 +02:00
|
|
|
values[Anum_pg_publication_pubtruncate - 1] =
|
2020-04-08 09:59:27 +02:00
|
|
|
BoolGetDatum(pubactions.pubtruncate);
|
|
|
|
values[Anum_pg_publication_pubviaroot - 1] =
|
|
|
|
BoolGetDatum(publish_via_partition_root);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = heap_form_tuple(RelationGetDescr(rel), values, nulls);
|
|
|
|
|
|
|
|
/* Insert tuple into catalog. */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
CatalogTupleInsert(rel, tup);
|
2017-01-19 18:00:00 +01:00
|
|
|
heap_freetuple(tup);
|
|
|
|
|
2017-01-20 20:45:02 +01:00
|
|
|
recordDependencyOnOwner(PublicationRelationId, puboid, GetUserId());
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
ObjectAddressSet(myself, PublicationRelationId, puboid);
|
|
|
|
|
|
|
|
/* Make the changes visible. */
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
|
|
|
if (stmt->tables)
|
|
|
|
{
|
|
|
|
List *rels;
|
|
|
|
|
|
|
|
Assert(list_length(stmt->tables) > 0);
|
|
|
|
|
|
|
|
rels = OpenTableList(stmt->tables);
|
|
|
|
PublicationAddTables(puboid, rels, true, NULL);
|
|
|
|
CloseTableList(rels);
|
|
|
|
}
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
InvokeObjectPostCreateHook(PublicationRelationId, puboid, 0);
|
|
|
|
|
2019-07-13 00:35:34 +02:00
|
|
|
if (wal_level != WAL_LEVEL_LOGICAL)
|
|
|
|
{
|
|
|
|
ereport(WARNING,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("wal_level is insufficient to publish logical changes"),
|
|
|
|
errhint("Set wal_level to logical before creating subscriptions.")));
|
|
|
|
}
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
return myself;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Change options of a publication.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
AlterPublicationOptions(AlterPublicationStmt *stmt, Relation rel,
|
2017-05-17 22:31:56 +02:00
|
|
|
HeapTuple tup)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
bool nulls[Natts_pg_publication];
|
|
|
|
bool replaces[Natts_pg_publication];
|
|
|
|
Datum values[Natts_pg_publication];
|
2017-05-12 14:57:01 +02:00
|
|
|
bool publish_given;
|
2020-04-08 09:59:27 +02:00
|
|
|
PublicationActions pubactions;
|
|
|
|
bool publish_via_partition_root_given;
|
|
|
|
bool publish_via_partition_root;
|
2017-05-17 22:31:56 +02:00
|
|
|
ObjectAddress obj;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_publication pubform;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
parse_publication_options(stmt->options,
|
2020-04-08 09:59:27 +02:00
|
|
|
&publish_given, &pubactions,
|
|
|
|
&publish_via_partition_root_given,
|
|
|
|
&publish_via_partition_root);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Everything ok, form a new tuple. */
|
|
|
|
memset(values, 0, sizeof(values));
|
|
|
|
memset(nulls, false, sizeof(nulls));
|
|
|
|
memset(replaces, false, sizeof(replaces));
|
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
if (publish_given)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
2020-04-08 09:59:27 +02:00
|
|
|
values[Anum_pg_publication_pubinsert - 1] = BoolGetDatum(pubactions.pubinsert);
|
2017-01-19 18:00:00 +01:00
|
|
|
replaces[Anum_pg_publication_pubinsert - 1] = true;
|
2017-05-12 14:57:01 +02:00
|
|
|
|
2020-04-08 09:59:27 +02:00
|
|
|
values[Anum_pg_publication_pubupdate - 1] = BoolGetDatum(pubactions.pubupdate);
|
2017-01-19 18:00:00 +01:00
|
|
|
replaces[Anum_pg_publication_pubupdate - 1] = true;
|
2017-05-12 14:57:01 +02:00
|
|
|
|
2020-04-08 09:59:27 +02:00
|
|
|
values[Anum_pg_publication_pubdelete - 1] = BoolGetDatum(pubactions.pubdelete);
|
2017-01-19 18:00:00 +01:00
|
|
|
replaces[Anum_pg_publication_pubdelete - 1] = true;
|
2018-04-07 17:24:53 +02:00
|
|
|
|
2020-04-08 09:59:27 +02:00
|
|
|
values[Anum_pg_publication_pubtruncate - 1] = BoolGetDatum(pubactions.pubtruncate);
|
2018-04-07 17:24:53 +02:00
|
|
|
replaces[Anum_pg_publication_pubtruncate - 1] = true;
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
2020-04-08 09:59:27 +02:00
|
|
|
if (publish_via_partition_root_given)
|
|
|
|
{
|
|
|
|
values[Anum_pg_publication_pubviaroot - 1] = BoolGetDatum(publish_via_partition_root);
|
|
|
|
replaces[Anum_pg_publication_pubviaroot - 1] = true;
|
|
|
|
}
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
tup = heap_modify_tuple(tup, RelationGetDescr(rel), values, nulls,
|
|
|
|
replaces);
|
|
|
|
|
|
|
|
/* Update the catalog. */
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(rel, &tup->t_self, tup);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
CommandCounterIncrement();
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
pubform = (Form_pg_publication) GETSTRUCT(tup);
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/* Invalidate the relcache. */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
if (pubform->puballtables)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
CacheInvalidateRelcacheAll();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-03-10 08:42:59 +01:00
|
|
|
/*
|
|
|
|
* For any partitioned tables contained in the publication, we must
|
|
|
|
* invalidate all partitions contained in the respective partition
|
|
|
|
* trees, not just those explicitly mentioned in the publication.
|
|
|
|
*/
|
|
|
|
List *relids = GetPublicationRelations(pubform->oid,
|
|
|
|
PUBLICATION_PART_ALL);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't want to send too many individual messages, at some point
|
|
|
|
* it's cheaper to just reset whole relcache.
|
|
|
|
*/
|
|
|
|
if (list_length(relids) < MAX_RELCACHE_INVAL_MSGS)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
ListCell *lc;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-17 22:31:56 +02:00
|
|
|
foreach(lc, relids)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
Oid relid = lfirst_oid(lc);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
CacheInvalidateRelcacheByRelid(relid);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
CacheInvalidateRelcacheAll();
|
|
|
|
}
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
ObjectAddressSet(obj, PublicationRelationId, pubform->oid);
|
2017-01-19 18:00:00 +01:00
|
|
|
EventTriggerCollectSimpleCommand(obj, InvalidObjectAddress,
|
|
|
|
(Node *) stmt);
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
InvokeObjectPostAlterHook(PublicationRelationId, pubform->oid, 0);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add or remove table to/from publication.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
AlterPublicationTables(AlterPublicationStmt *stmt, Relation rel,
|
|
|
|
HeapTuple tup)
|
|
|
|
{
|
|
|
|
List *rels = NIL;
|
|
|
|
Form_pg_publication pubform = (Form_pg_publication) GETSTRUCT(tup);
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Oid pubid = pubform->oid;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Check that user is allowed to manipulate the publication tables. */
|
|
|
|
if (pubform->puballtables)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
|
|
|
|
errmsg("publication \"%s\" is defined as FOR ALL TABLES",
|
|
|
|
NameStr(pubform->pubname)),
|
|
|
|
errdetail("Tables cannot be added to or dropped from FOR ALL TABLES publications.")));
|
|
|
|
|
|
|
|
Assert(list_length(stmt->tables) > 0);
|
|
|
|
|
|
|
|
rels = OpenTableList(stmt->tables);
|
|
|
|
|
|
|
|
if (stmt->tableAction == DEFELEM_ADD)
|
|
|
|
PublicationAddTables(pubid, rels, false, stmt);
|
|
|
|
else if (stmt->tableAction == DEFELEM_DROP)
|
|
|
|
PublicationDropTables(pubid, rels, false);
|
2017-06-21 20:39:04 +02:00
|
|
|
else /* DEFELEM_SET */
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
2020-03-10 08:42:59 +01:00
|
|
|
List *oldrelids = GetPublicationRelations(pubid,
|
|
|
|
PUBLICATION_PART_ROOT);
|
2017-01-19 18:00:00 +01:00
|
|
|
List *delrels = NIL;
|
|
|
|
ListCell *oldlc;
|
|
|
|
|
|
|
|
/* Calculate which relations to drop. */
|
|
|
|
foreach(oldlc, oldrelids)
|
|
|
|
{
|
|
|
|
Oid oldrelid = lfirst_oid(oldlc);
|
|
|
|
ListCell *newlc;
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
foreach(newlc, rels)
|
|
|
|
{
|
|
|
|
Relation newrel = (Relation) lfirst(newlc);
|
|
|
|
|
|
|
|
if (RelationGetRelid(newrel) == oldrelid)
|
|
|
|
{
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
{
|
2019-01-21 19:32:19 +01:00
|
|
|
Relation oldrel = table_open(oldrelid,
|
|
|
|
ShareUpdateExclusiveLock);
|
2017-05-17 22:31:56 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
delrels = lappend(delrels, oldrel);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* And drop them. */
|
|
|
|
PublicationDropTables(pubid, delrels, true);
|
|
|
|
|
|
|
|
/*
|
2017-05-17 22:31:56 +02:00
|
|
|
* Don't bother calculating the difference for adding, we'll catch and
|
|
|
|
* skip existing ones when doing catalog update.
|
2017-01-19 18:00:00 +01:00
|
|
|
*/
|
|
|
|
PublicationAddTables(pubid, rels, true, stmt);
|
|
|
|
|
|
|
|
CloseTableList(delrels);
|
|
|
|
}
|
|
|
|
|
|
|
|
CloseTableList(rels);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Alter the existing publication.
|
|
|
|
*
|
|
|
|
* This is dispatcher function for AlterPublicationOptions and
|
|
|
|
* AlterPublicationTables.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
AlterPublication(AlterPublicationStmt *stmt)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
Relation rel;
|
|
|
|
HeapTuple tup;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_publication pubform;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = SearchSysCacheCopy1(PUBLICATIONNAME,
|
|
|
|
CStringGetDatum(stmt->pubname));
|
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tup))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("publication \"%s\" does not exist",
|
|
|
|
stmt->pubname)));
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
pubform = (Form_pg_publication) GETSTRUCT(tup);
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/* must be owner */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
if (!pg_publication_ownercheck(pubform->oid, GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_PUBLICATION,
|
2017-01-19 18:00:00 +01:00
|
|
|
stmt->pubname);
|
|
|
|
|
|
|
|
if (stmt->options)
|
|
|
|
AlterPublicationOptions(stmt, rel, tup);
|
|
|
|
else
|
|
|
|
AlterPublicationTables(stmt, rel, tup);
|
|
|
|
|
|
|
|
/* Cleanup. */
|
|
|
|
heap_freetuple(tup);
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Drop publication by OID
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RemovePublicationById(Oid pubid)
|
|
|
|
{
|
|
|
|
Relation rel;
|
|
|
|
HeapTuple tup;
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = SearchSysCache1(PUBLICATIONOID, ObjectIdGetDatum(pubid));
|
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tup))
|
|
|
|
elog(ERROR, "cache lookup failed for publication %u", pubid);
|
|
|
|
|
2017-02-01 22:13:30 +01:00
|
|
|
CatalogTupleDelete(rel, &tup->t_self);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
ReleaseSysCache(tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove relation from publication by mapping OID.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RemovePublicationRelById(Oid proid)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
Relation rel;
|
|
|
|
HeapTuple tup;
|
|
|
|
Form_pg_publication_rel pubrel;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = SearchSysCache1(PUBLICATIONREL, ObjectIdGetDatum(proid));
|
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tup))
|
|
|
|
elog(ERROR, "cache lookup failed for publication table %u",
|
|
|
|
proid);
|
|
|
|
|
|
|
|
pubrel = (Form_pg_publication_rel) GETSTRUCT(tup);
|
|
|
|
|
|
|
|
/* Invalidate relcache so that publication info is rebuilt. */
|
|
|
|
CacheInvalidateRelcacheByRelid(pubrel->prrelid);
|
|
|
|
|
2017-02-01 22:13:30 +01:00
|
|
|
CatalogTupleDelete(rel, &tup->t_self);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
ReleaseSysCache(tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-12-07 17:02:39 +01:00
|
|
|
* Open relations specified by a RangeVar list.
|
2020-03-10 08:42:59 +01:00
|
|
|
* The returned tables are locked in ShareUpdateExclusiveLock mode in order to
|
|
|
|
* add them to a publication.
|
2017-01-19 18:00:00 +01:00
|
|
|
*/
|
|
|
|
static List *
|
|
|
|
OpenTableList(List *tables)
|
|
|
|
{
|
|
|
|
List *relids = NIL;
|
|
|
|
List *rels = NIL;
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Open, share-lock, and check all the explicitly-specified relations
|
|
|
|
*/
|
|
|
|
foreach(lc, tables)
|
|
|
|
{
|
2018-12-07 17:02:39 +01:00
|
|
|
RangeVar *rv = castNode(RangeVar, lfirst(lc));
|
2017-01-19 18:00:00 +01:00
|
|
|
bool recurse = rv->inh;
|
2018-12-07 17:02:39 +01:00
|
|
|
Relation rel;
|
2017-01-19 18:00:00 +01:00
|
|
|
Oid myrelid;
|
|
|
|
|
2018-12-07 17:02:39 +01:00
|
|
|
/* Allow query cancel in case this takes a long time */
|
2017-01-19 18:00:00 +01:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_openrv(rv, ShareUpdateExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
myrelid = RelationGetRelid(rel);
|
2017-05-17 02:36:35 +02:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
/*
|
2017-05-17 02:36:35 +02:00
|
|
|
* Filter out duplicates if user specifies "foo, foo".
|
|
|
|
*
|
2017-03-23 10:14:42 +01:00
|
|
|
* Note that this algorithm is known to not be very efficient (O(N^2))
|
2017-01-19 18:00:00 +01:00
|
|
|
* but given that it only works on list of tables given to us by user
|
|
|
|
* it's deemed acceptable.
|
|
|
|
*/
|
|
|
|
if (list_member_oid(relids, myrelid))
|
|
|
|
{
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, ShareUpdateExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
continue;
|
|
|
|
}
|
2018-12-07 17:02:39 +01:00
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
rels = lappend(rels, rel);
|
|
|
|
relids = lappend_oid(relids, myrelid);
|
|
|
|
|
2020-03-10 08:42:59 +01:00
|
|
|
/*
|
|
|
|
* Add children of this rel, if requested, so that they too are added
|
|
|
|
* to the publication. A partitioned table can't have any inheritance
|
|
|
|
* children other than its partitions, which need not be explicitly
|
|
|
|
* added to the publication.
|
|
|
|
*/
|
|
|
|
if (recurse && rel->rd_rel->relkind != RELKIND_PARTITIONED_TABLE)
|
2017-01-19 18:00:00 +01:00
|
|
|
{
|
|
|
|
List *children;
|
2018-12-07 17:02:39 +01:00
|
|
|
ListCell *child;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
children = find_all_inheritors(myrelid, ShareUpdateExclusiveLock,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
foreach(child, children)
|
|
|
|
{
|
|
|
|
Oid childrelid = lfirst_oid(child);
|
|
|
|
|
2018-12-07 17:02:39 +01:00
|
|
|
/* Allow query cancel in case this takes a long time */
|
|
|
|
CHECK_FOR_INTERRUPTS();
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip duplicates if user specified both parent and child
|
|
|
|
* tables.
|
|
|
|
*/
|
|
|
|
if (list_member_oid(relids, childrelid))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* find_all_inheritors already got lock */
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(childrelid, NoLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
rels = lappend(rels, rel);
|
|
|
|
relids = lappend_oid(relids, childrelid);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
list_free(relids);
|
|
|
|
|
|
|
|
return rels;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Close all relations in the list.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
CloseTableList(List *rels)
|
|
|
|
{
|
|
|
|
ListCell *lc;
|
|
|
|
|
|
|
|
foreach(lc, rels)
|
|
|
|
{
|
|
|
|
Relation rel = (Relation) lfirst(lc);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, NoLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add listed tables to the publication.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
PublicationAddTables(Oid pubid, List *rels, bool if_not_exists,
|
|
|
|
AlterPublicationStmt *stmt)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
ListCell *lc;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
Assert(!stmt || !stmt->for_all_tables);
|
|
|
|
|
|
|
|
foreach(lc, rels)
|
|
|
|
{
|
|
|
|
Relation rel = (Relation) lfirst(lc);
|
2017-05-17 22:31:56 +02:00
|
|
|
ObjectAddress obj;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Must be owner of the table or superuser. */
|
|
|
|
if (!pg_class_ownercheck(RelationGetRelid(rel), GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, get_relkind_objtype(rel->rd_rel->relkind),
|
2017-01-19 18:00:00 +01:00
|
|
|
RelationGetRelationName(rel));
|
|
|
|
|
|
|
|
obj = publication_add_relation(pubid, rel, if_not_exists);
|
|
|
|
if (stmt)
|
|
|
|
{
|
|
|
|
EventTriggerCollectSimpleCommand(obj, InvalidObjectAddress,
|
|
|
|
(Node *) stmt);
|
|
|
|
|
|
|
|
InvokeObjectPostCreateHook(PublicationRelRelationId,
|
|
|
|
obj.objectId, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove listed tables from the publication.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
PublicationDropTables(Oid pubid, List *rels, bool missing_ok)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
ObjectAddress obj;
|
|
|
|
ListCell *lc;
|
|
|
|
Oid prid;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
foreach(lc, rels)
|
|
|
|
{
|
|
|
|
Relation rel = (Relation) lfirst(lc);
|
|
|
|
Oid relid = RelationGetRelid(rel);
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
prid = GetSysCacheOid2(PUBLICATIONRELMAP, Anum_pg_publication_rel_oid,
|
|
|
|
ObjectIdGetDatum(relid),
|
2017-01-19 18:00:00 +01:00
|
|
|
ObjectIdGetDatum(pubid));
|
|
|
|
if (!OidIsValid(prid))
|
|
|
|
{
|
|
|
|
if (missing_ok)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("relation \"%s\" is not part of the publication",
|
|
|
|
RelationGetRelationName(rel))));
|
|
|
|
}
|
|
|
|
|
|
|
|
ObjectAddressSet(obj, PublicationRelRelationId, prid);
|
|
|
|
performDeletion(&obj, DROP_CASCADE, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal workhorse for changing a publication owner
|
|
|
|
*/
|
2017-05-17 22:31:56 +02:00
|
|
|
static void
|
2017-01-19 18:00:00 +01:00
|
|
|
AlterPublicationOwner_internal(Relation rel, HeapTuple tup, Oid newOwnerId)
|
|
|
|
{
|
|
|
|
Form_pg_publication form;
|
|
|
|
|
|
|
|
form = (Form_pg_publication) GETSTRUCT(tup);
|
|
|
|
|
|
|
|
if (form->pubowner == newOwnerId)
|
|
|
|
return;
|
|
|
|
|
2017-02-13 14:57:45 +01:00
|
|
|
if (!superuser())
|
|
|
|
{
|
|
|
|
AclResult aclresult;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-02-13 14:57:45 +01:00
|
|
|
/* Must be owner */
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
if (!pg_publication_ownercheck(form->oid, GetUserId()))
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(ACLCHECK_NOT_OWNER, OBJECT_PUBLICATION,
|
2017-02-13 14:57:45 +01:00
|
|
|
NameStr(form->pubname));
|
|
|
|
|
|
|
|
/* Must be able to become new owner */
|
|
|
|
check_is_member_of_role(GetUserId(), newOwnerId);
|
|
|
|
|
|
|
|
/* New owner must have CREATE privilege on database */
|
|
|
|
aclresult = pg_database_aclcheck(MyDatabaseId, newOwnerId, ACL_CREATE);
|
|
|
|
if (aclresult != ACLCHECK_OK)
|
2017-12-02 15:26:34 +01:00
|
|
|
aclcheck_error(aclresult, OBJECT_DATABASE,
|
2017-02-13 14:57:45 +01:00
|
|
|
get_database_name(MyDatabaseId));
|
|
|
|
|
|
|
|
if (form->puballtables && !superuser_arg(newOwnerId))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("permission denied to change owner of publication \"%s\"",
|
|
|
|
NameStr(form->pubname)),
|
2017-02-13 14:57:45 +01:00
|
|
|
errhint("The owner of a FOR ALL TABLES publication must be a superuser.")));
|
|
|
|
}
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
form->pubowner = newOwnerId;
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(rel, &tup->t_self, tup);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
/* Update owner dependency reference */
|
|
|
|
changeDependencyOnOwner(PublicationRelationId,
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
form->oid,
|
2017-01-19 18:00:00 +01:00
|
|
|
newOwnerId);
|
|
|
|
|
|
|
|
InvokeObjectPostAlterHook(PublicationRelationId,
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
form->oid, 0);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Change publication owner -- by name
|
|
|
|
*/
|
|
|
|
ObjectAddress
|
|
|
|
AlterPublicationOwner(const char *name, Oid newOwnerId)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
Oid subid;
|
|
|
|
HeapTuple tup;
|
|
|
|
Relation rel;
|
2017-01-19 18:00:00 +01:00
|
|
|
ObjectAddress address;
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
Form_pg_publication pubform;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = SearchSysCacheCopy1(PUBLICATIONNAME, CStringGetDatum(name));
|
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tup))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("publication \"%s\" does not exist", name)));
|
|
|
|
|
Remove WITH OIDS support, change oid catalog column visibility.
Previously tables declared WITH OIDS, including a significant fraction
of the catalog tables, stored the oid column not as a normal column,
but as part of the tuple header.
This special column was not shown by default, which was somewhat odd,
as it's often (consider e.g. pg_class.oid) one of the more important
parts of a row. Neither pg_dump nor COPY included the contents of the
oid column by default.
The fact that the oid column was not an ordinary column necessitated a
significant amount of special case code to support oid columns. That
already was painful for the existing, but upcoming work aiming to make
table storage pluggable, would have required expanding and duplicating
that "specialness" significantly.
WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0).
Remove it.
Removing includes:
- CREATE TABLE and ALTER TABLE syntax for declaring the table to be
WITH OIDS has been removed (WITH (oids[ = true]) will error out)
- pg_dump does not support dumping tables declared WITH OIDS and will
issue a warning when dumping one (and ignore the oid column).
- restoring an pg_dump archive with pg_restore will warn when
restoring a table with oid contents (and ignore the oid column)
- COPY will refuse to load binary dump that includes oids.
- pg_upgrade will error out when encountering tables declared WITH
OIDS, they have to be altered to remove the oid column first.
- Functionality to access the oid of the last inserted row (like
plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed.
The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false)
for CREATE TABLE) is still supported. While that requires a bit of
support code, it seems unnecessary to break applications / dumps that
do not use oids, and are explicit about not using them.
The biggest user of WITH OID columns was postgres' catalog. This
commit changes all 'magic' oid columns to be columns that are normally
declared and stored. To reduce unnecessary query breakage all the
newly added columns are still named 'oid', even if a table's column
naming scheme would indicate 'reloid' or such. This obviously
requires adapting a lot code, mostly replacing oid access via
HeapTupleGetOid() with access to the underlying Form_pg_*->oid column.
The bootstrap process now assigns oids for all oid columns in
genbki.pl that do not have an explicit value (starting at the largest
oid previously used), only oids assigned later by oids will be above
FirstBootstrapObjectId. As the oid column now is a normal column the
special bootstrap syntax for oids has been removed.
Oids are not automatically assigned during insertion anymore, all
backend code explicitly assigns oids with GetNewOidWithIndex(). For
the rare case that insertions into the catalog via SQL are called for
the new pg_nextoid() function can be used (which only works on catalog
tables).
The fact that oid columns on system tables are now normal columns
means that they will be included in the set of columns expanded
by * (i.e. SELECT * FROM pg_class will now include the table's oid,
previously it did not). It'd not technically be hard to hide oid
column by default, but that'd mean confusing behavior would either
have to be carried forward forever, or it'd cause breakage down the
line.
While it's not unlikely that further adjustments are needed, the
scope/invasiveness of the patch makes it worthwhile to get merge this
now. It's painful to maintain externally, too complicated to commit
after the code code freeze, and a dependency of a number of other
patches.
Catversion bump, for obvious reasons.
Author: Andres Freund, with contributions by John Naylor
Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
2018-11-21 00:36:57 +01:00
|
|
|
pubform = (Form_pg_publication) GETSTRUCT(tup);
|
|
|
|
subid = pubform->oid;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
AlterPublicationOwner_internal(rel, tup, newOwnerId);
|
|
|
|
|
|
|
|
ObjectAddressSet(address, PublicationRelationId, subid);
|
|
|
|
|
|
|
|
heap_freetuple(tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
return address;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Change publication owner -- by OID
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
AlterPublicationOwner_oid(Oid subid, Oid newOwnerId)
|
|
|
|
{
|
2017-05-17 22:31:56 +02:00
|
|
|
HeapTuple tup;
|
|
|
|
Relation rel;
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
rel = table_open(PublicationRelationId, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
|
|
|
|
tup = SearchSysCacheCopy1(PUBLICATIONOID, ObjectIdGetDatum(subid));
|
|
|
|
|
|
|
|
if (!HeapTupleIsValid(tup))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_UNDEFINED_OBJECT),
|
|
|
|
errmsg("publication with OID %u does not exist", subid)));
|
|
|
|
|
|
|
|
AlterPublicationOwner_internal(rel, tup, newOwnerId);
|
|
|
|
|
|
|
|
heap_freetuple(tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(rel, RowExclusiveLock);
|
2017-01-19 18:00:00 +01:00
|
|
|
}
|