2007-04-02 05:49:42 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pg_enum.c
|
|
|
|
* routines to support manipulation of the pg_enum relation
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Copyright (c) 2006-2019, PostgreSQL Global Development Group
|
2007-04-02 05:49:42 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/catalog/pg_enum.c
|
2007-04-02 05:49:42 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
2012-08-30 22:15:44 +02:00
|
|
|
#include "access/htup_details.h"
|
2019-12-25 02:23:39 +01:00
|
|
|
#include "access/indexgenam.h"
|
2019-01-21 19:18:20 +01:00
|
|
|
#include "access/table.h"
|
2010-10-25 05:04:37 +02:00
|
|
|
#include "access/xact.h"
|
2013-12-19 22:10:01 +01:00
|
|
|
#include "catalog/binary_upgrade.h"
|
2007-04-02 05:49:42 +02:00
|
|
|
#include "catalog/catalog.h"
|
|
|
|
#include "catalog/indexing.h"
|
|
|
|
#include "catalog/pg_enum.h"
|
2010-10-25 05:04:37 +02:00
|
|
|
#include "catalog/pg_type.h"
|
2011-04-25 18:00:21 +02:00
|
|
|
#include "miscadmin.h"
|
2016-11-29 18:00:00 +01:00
|
|
|
#include "nodes/value.h"
|
2019-11-12 04:00:16 +01:00
|
|
|
#include "storage/lmgr.h"
|
2007-04-02 05:49:42 +02:00
|
|
|
#include "utils/builtins.h"
|
2012-08-29 00:26:24 +02:00
|
|
|
#include "utils/catcache.h"
|
2007-04-02 05:49:42 +02:00
|
|
|
#include "utils/fmgroids.h"
|
2018-10-09 01:51:01 +02:00
|
|
|
#include "utils/hsearch.h"
|
|
|
|
#include "utils/memutils.h"
|
2010-10-25 05:04:37 +02:00
|
|
|
#include "utils/syscache.h"
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2015-03-11 03:33:25 +01:00
|
|
|
/* Potentially set by pg_upgrade_support functions */
|
2011-04-10 17:42:00 +02:00
|
|
|
Oid binary_upgrade_next_pg_enum_oid = InvalidOid;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
2018-10-09 01:51:01 +02:00
|
|
|
/*
|
|
|
|
* Hash table of enum value OIDs created during the current transaction by
|
|
|
|
* AddEnumLabel. We disallow using these values until the transaction is
|
|
|
|
* committed; otherwise, they might get into indexes where we can't clean
|
|
|
|
* them up, and then if the transaction rolls back we have a broken index.
|
|
|
|
* (See comments for check_safe_enum_use() in enum.c.) Values created by
|
|
|
|
* EnumValuesCreate are *not* blacklisted; we assume those are created during
|
|
|
|
* CREATE TYPE, so they can't go away unless the enum type itself does.
|
|
|
|
*/
|
|
|
|
static HTAB *enum_blacklist = NULL;
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
static void RenumberEnumType(Relation pg_enum, HeapTuple *existing, int nelems);
|
|
|
|
static int sort_order_cmp(const void *p1, const void *p2);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* EnumValuesCreate
|
|
|
|
* Create an entry in pg_enum for each of the supplied enum values.
|
|
|
|
*
|
|
|
|
* vals is a list of Value strings.
|
|
|
|
*/
|
|
|
|
void
|
2010-10-25 05:04:37 +02:00
|
|
|
EnumValuesCreate(Oid enumTypeOid, List *vals)
|
2007-04-02 05:49:42 +02:00
|
|
|
{
|
|
|
|
Relation pg_enum;
|
|
|
|
NameData enumlabel;
|
|
|
|
Oid *oids;
|
2009-12-24 23:17:58 +01:00
|
|
|
int elemno,
|
|
|
|
num_elems;
|
2007-04-02 05:49:42 +02:00
|
|
|
Datum values[Natts_pg_enum];
|
2008-11-02 02:45:28 +01:00
|
|
|
bool nulls[Natts_pg_enum];
|
2007-04-02 05:49:42 +02:00
|
|
|
ListCell *lc;
|
2007-11-15 22:14:46 +01:00
|
|
|
HeapTuple tup;
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2009-12-24 23:17:58 +01:00
|
|
|
num_elems = list_length(vals);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* We do not bother to check the list of values for duplicates --- if you
|
|
|
|
* have any, you'll get a less-than-friendly unique-index violation. It is
|
|
|
|
* probably not worth trying harder.
|
2007-04-02 05:49:42 +02:00
|
|
|
*/
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_enum = table_open(EnumRelationId, RowExclusiveLock);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
|
|
|
/*
|
2010-10-25 05:04:37 +02:00
|
|
|
* Allocate OIDs for the enum's members.
|
|
|
|
*
|
|
|
|
* While this method does not absolutely guarantee that we generate no
|
2011-04-10 17:42:00 +02:00
|
|
|
* duplicate OIDs (since we haven't entered each oid into the table before
|
|
|
|
* allocating the next), trouble could only occur if the OID counter wraps
|
|
|
|
* all the way around before we finish. Which seems unlikely.
|
2007-04-02 05:49:42 +02:00
|
|
|
*/
|
2009-12-24 23:17:58 +01:00
|
|
|
oids = (Oid *) palloc(num_elems * sizeof(Oid));
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
for (elemno = 0; elemno < num_elems; elemno++)
|
2007-04-02 05:49:42 +02:00
|
|
|
{
|
2009-12-19 01:47:57 +01:00
|
|
|
/*
|
2010-10-25 05:04:37 +02:00
|
|
|
* We assign even-numbered OIDs to all the new enum labels. This
|
|
|
|
* tells the comparison functions the OIDs are in the correct sort
|
|
|
|
* order and can be compared directly.
|
2009-12-19 01:47:57 +01:00
|
|
|
*/
|
2011-04-10 17:42:00 +02:00
|
|
|
Oid new_oid;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
2011-04-10 17:42:00 +02:00
|
|
|
do
|
|
|
|
{
|
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
|
|
|
new_oid = GetNewOidWithIndex(pg_enum, EnumOidIndexId,
|
|
|
|
Anum_pg_enum_oid);
|
2010-10-25 05:04:37 +02:00
|
|
|
} while (new_oid & 1);
|
|
|
|
oids[elemno] = new_oid;
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
/* sort them, just in case OID counter wrapped from high to low */
|
|
|
|
qsort(oids, num_elems, sizeof(Oid), oid_cmp);
|
|
|
|
|
2007-04-02 05:49:42 +02:00
|
|
|
/* and make the entries */
|
2008-11-02 02:45:28 +01:00
|
|
|
memset(nulls, false, sizeof(nulls));
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2009-12-24 23:17:58 +01:00
|
|
|
elemno = 0;
|
2007-04-02 05:49:42 +02:00
|
|
|
foreach(lc, vals)
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
char *lab = strVal(lfirst(lc));
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2007-11-15 22:14:46 +01:00
|
|
|
/*
|
2007-04-03 00:14:17 +02:00
|
|
|
* labels are stored in a name field, for easier syscache lookup, so
|
|
|
|
* check the length to make sure it's within range.
|
|
|
|
*/
|
|
|
|
if (strlen(lab) > (NAMEDATALEN - 1))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_NAME),
|
2008-01-20 18:50:41 +01:00
|
|
|
errmsg("invalid enum label \"%s\"", lab),
|
|
|
|
errdetail("Labels must be %d characters or less.",
|
|
|
|
NAMEDATALEN - 1)));
|
2007-04-03 00:14:17 +02: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
|
|
|
values[Anum_pg_enum_oid - 1] = ObjectIdGetDatum(oids[elemno]);
|
2007-04-02 05:49:42 +02:00
|
|
|
values[Anum_pg_enum_enumtypid - 1] = ObjectIdGetDatum(enumTypeOid);
|
2010-10-25 05:04:37 +02:00
|
|
|
values[Anum_pg_enum_enumsortorder - 1] = Float4GetDatum(elemno + 1);
|
2007-04-02 05:49:42 +02:00
|
|
|
namestrcpy(&enumlabel, lab);
|
|
|
|
values[Anum_pg_enum_enumlabel - 1] = NameGetDatum(&enumlabel);
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
tup = heap_form_tuple(RelationGetDescr(pg_enum), values, nulls);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleInsert(pg_enum, tup);
|
2007-04-02 05:49:42 +02:00
|
|
|
heap_freetuple(tup);
|
|
|
|
|
2009-12-24 23:17:58 +01:00
|
|
|
elemno++;
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* clean up */
|
|
|
|
pfree(oids);
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_enum, RowExclusiveLock);
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* EnumValuesDelete
|
|
|
|
* Remove all the pg_enum entries for the specified enum type.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
EnumValuesDelete(Oid enumTypeOid)
|
|
|
|
{
|
|
|
|
Relation pg_enum;
|
|
|
|
ScanKeyData key[1];
|
|
|
|
SysScanDesc scan;
|
|
|
|
HeapTuple tup;
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_enum = table_open(EnumRelationId, RowExclusiveLock);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
|
|
|
ScanKeyInit(&key[0],
|
|
|
|
Anum_pg_enum_enumtypid,
|
|
|
|
BTEqualStrategyNumber, F_OIDEQ,
|
|
|
|
ObjectIdGetDatum(enumTypeOid));
|
|
|
|
|
|
|
|
scan = systable_beginscan(pg_enum, EnumTypIdLabelIndexId, true,
|
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans.
SnapshotNow scans have the undesirable property that, in the face of
concurrent updates, the scan can fail to see either the old or the new
versions of the row. In many cases, we work around this by requiring
DDL operations to hold AccessExclusiveLock on the object being
modified; in some cases, the existing locking is inadequate and random
failures occur as a result. This commit doesn't change anything
related to locking, but will hopefully pave the way to allowing lock
strength reductions in the future.
The major issue has held us back from making this change in the past
is that taking an MVCC snapshot is significantly more expensive than
using a static special snapshot such as SnapshotNow. However, testing
of various worst-case scenarios reveals that this problem is not
severe except under fairly extreme workloads. To mitigate those
problems, we avoid retaking the MVCC snapshot for each new scan;
instead, we take a new snapshot only when invalidation messages have
been processed. The catcache machinery already requires that
invalidation messages be sent before releasing the related heavyweight
lock; else other backends might rely on locally-cached data rather
than scanning the catalog at all. Thus, making snapshot reuse
dependent on the same guarantees shouldn't break anything that wasn't
already subtly broken.
Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
|
|
|
NULL, 1, key);
|
2007-04-02 05:49:42 +02:00
|
|
|
|
|
|
|
while (HeapTupleIsValid(tup = systable_getnext(scan)))
|
|
|
|
{
|
2017-02-01 22:13:30 +01:00
|
|
|
CatalogTupleDelete(pg_enum, &tup->t_self);
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
systable_endscan(scan);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_enum, RowExclusiveLock);
|
2007-04-02 05:49:42 +02:00
|
|
|
}
|
|
|
|
|
2018-10-09 01:51:01 +02:00
|
|
|
/*
|
|
|
|
* Initialize the enum blacklist for this transaction.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
init_enum_blacklist(void)
|
|
|
|
{
|
|
|
|
HASHCTL hash_ctl;
|
|
|
|
|
|
|
|
memset(&hash_ctl, 0, sizeof(hash_ctl));
|
|
|
|
hash_ctl.keysize = sizeof(Oid);
|
|
|
|
hash_ctl.entrysize = sizeof(Oid);
|
|
|
|
hash_ctl.hcxt = TopTransactionContext;
|
|
|
|
enum_blacklist = hash_create("Enum value blacklist",
|
|
|
|
32,
|
|
|
|
&hash_ctl,
|
|
|
|
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
|
|
|
|
}
|
2007-04-02 05:49:42 +02:00
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
/*
|
|
|
|
* AddEnumLabel
|
|
|
|
* Add a new label to the enum set. By default it goes at
|
|
|
|
* the end, but the user can choose to place it before or
|
|
|
|
* after any existing set member.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
AddEnumLabel(Oid enumTypeOid,
|
|
|
|
const char *newVal,
|
|
|
|
const char *neighbor,
|
2012-09-22 18:53:31 +02:00
|
|
|
bool newValIsAfter,
|
2013-05-29 22:58:43 +02:00
|
|
|
bool skipIfExists)
|
2010-10-25 05:04:37 +02:00
|
|
|
{
|
|
|
|
Relation pg_enum;
|
|
|
|
Oid newOid;
|
|
|
|
Datum values[Natts_pg_enum];
|
|
|
|
bool nulls[Natts_pg_enum];
|
|
|
|
NameData enumlabel;
|
|
|
|
HeapTuple enum_tup;
|
|
|
|
float4 newelemorder;
|
|
|
|
HeapTuple *existing;
|
|
|
|
CatCList *list;
|
|
|
|
int nelems;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* check length of new label is ok */
|
|
|
|
if (strlen(newVal) > (NAMEDATALEN - 1))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_NAME),
|
|
|
|
errmsg("invalid enum label \"%s\"", newVal),
|
|
|
|
errdetail("Labels must be %d characters or less.",
|
|
|
|
NAMEDATALEN - 1)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Acquire a lock on the enum type, which we won't release until commit.
|
|
|
|
* This ensures that two backends aren't concurrently modifying the same
|
2011-04-10 17:42:00 +02:00
|
|
|
* enum type. Without that, we couldn't be sure to get a consistent view
|
|
|
|
* of the enum members via the syscache. Note that this does not block
|
|
|
|
* other backends from inspecting the type; see comments for
|
2010-10-25 05:04:37 +02:00
|
|
|
* RenumberEnumType.
|
|
|
|
*/
|
|
|
|
LockDatabaseObject(TypeRelationId, enumTypeOid, 0, ExclusiveLock);
|
|
|
|
|
2012-09-23 00:35:22 +02:00
|
|
|
/*
|
|
|
|
* Check if label is already in use. The unique index on pg_enum would
|
|
|
|
* catch this anyway, but we prefer a friendlier error message, and
|
|
|
|
* besides we need a check to support IF NOT EXISTS.
|
|
|
|
*/
|
|
|
|
enum_tup = SearchSysCache2(ENUMTYPOIDNAME,
|
|
|
|
ObjectIdGetDatum(enumTypeOid),
|
|
|
|
CStringGetDatum(newVal));
|
|
|
|
if (HeapTupleIsValid(enum_tup))
|
2012-09-22 18:53:31 +02:00
|
|
|
{
|
2012-09-23 00:35:22 +02:00
|
|
|
ReleaseSysCache(enum_tup);
|
|
|
|
if (skipIfExists)
|
2012-09-22 18:53:31 +02:00
|
|
|
{
|
2012-09-23 00:35:22 +02:00
|
|
|
ereport(NOTICE,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
errmsg("enum label \"%s\" already exists, skipping",
|
|
|
|
newVal)));
|
2012-09-22 18:53:31 +02:00
|
|
|
return;
|
|
|
|
}
|
2012-09-23 00:35:22 +02:00
|
|
|
else
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
errmsg("enum label \"%s\" already exists",
|
|
|
|
newVal)));
|
2012-09-22 18:53:31 +02:00
|
|
|
}
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_enum = table_open(EnumRelationId, RowExclusiveLock);
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
/* If we have to renumber the existing members, we restart from here */
|
|
|
|
restart:
|
|
|
|
|
|
|
|
/* Get the list of existing members of the enum */
|
|
|
|
list = SearchSysCacheList1(ENUMTYPOIDNAME,
|
|
|
|
ObjectIdGetDatum(enumTypeOid));
|
2011-04-10 17:42:00 +02:00
|
|
|
nelems = list->n_members;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
/* Sort the existing members by enumsortorder */
|
|
|
|
existing = (HeapTuple *) palloc(nelems * sizeof(HeapTuple));
|
|
|
|
for (i = 0; i < nelems; i++)
|
|
|
|
existing[i] = &(list->members[i]->tuple);
|
|
|
|
|
|
|
|
qsort(existing, nelems, sizeof(HeapTuple), sort_order_cmp);
|
|
|
|
|
|
|
|
if (neighbor == NULL)
|
|
|
|
{
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Put the new label at the end of the list. No change to existing
|
|
|
|
* tuples is required.
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
if (nelems > 0)
|
|
|
|
{
|
|
|
|
Form_pg_enum en = (Form_pg_enum) GETSTRUCT(existing[nelems - 1]);
|
|
|
|
|
|
|
|
newelemorder = en->enumsortorder + 1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
newelemorder = 1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* BEFORE or AFTER was specified */
|
2011-04-10 17:42:00 +02:00
|
|
|
int nbr_index;
|
|
|
|
int other_nbr_index;
|
|
|
|
Form_pg_enum nbr_en;
|
|
|
|
Form_pg_enum other_nbr_en;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
/* Locate the neighbor element */
|
|
|
|
for (nbr_index = 0; nbr_index < nelems; nbr_index++)
|
|
|
|
{
|
|
|
|
Form_pg_enum en = (Form_pg_enum) GETSTRUCT(existing[nbr_index]);
|
|
|
|
|
|
|
|
if (strcmp(NameStr(en->enumlabel), neighbor) == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (nbr_index >= nelems)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("\"%s\" is not an existing enum label",
|
|
|
|
neighbor)));
|
|
|
|
nbr_en = (Form_pg_enum) GETSTRUCT(existing[nbr_index]);
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Attempt to assign an appropriate enumsortorder value: one less than
|
|
|
|
* the smallest member, one more than the largest member, or halfway
|
|
|
|
* between two existing members.
|
2010-10-25 05:04:37 +02:00
|
|
|
*
|
|
|
|
* In the "halfway" case, because of the finite precision of float4,
|
2011-04-10 17:42:00 +02:00
|
|
|
* we might compute a value that's actually equal to one or the other
|
|
|
|
* of its neighbors. In that case we renumber the existing members
|
|
|
|
* and try again.
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
if (newValIsAfter)
|
|
|
|
other_nbr_index = nbr_index + 1;
|
|
|
|
else
|
|
|
|
other_nbr_index = nbr_index - 1;
|
|
|
|
|
|
|
|
if (other_nbr_index < 0)
|
|
|
|
newelemorder = nbr_en->enumsortorder - 1;
|
|
|
|
else if (other_nbr_index >= nelems)
|
|
|
|
newelemorder = nbr_en->enumsortorder + 1;
|
|
|
|
else
|
|
|
|
{
|
2010-10-25 07:13:22 +02:00
|
|
|
/*
|
2016-08-31 19:58:01 +02:00
|
|
|
* The midpoint value computed here has to be rounded to float4
|
|
|
|
* precision, else our equality comparisons against the adjacent
|
|
|
|
* values are meaningless. The most portable way of forcing that
|
|
|
|
* to happen with non-C-standard-compliant compilers is to store
|
|
|
|
* it into a volatile variable.
|
2010-10-25 07:13:22 +02:00
|
|
|
*/
|
2016-08-31 19:58:01 +02:00
|
|
|
volatile float4 midpoint;
|
2010-10-25 07:13:22 +02:00
|
|
|
|
2016-08-31 19:58:01 +02:00
|
|
|
other_nbr_en = (Form_pg_enum) GETSTRUCT(existing[other_nbr_index]);
|
|
|
|
midpoint = (nbr_en->enumsortorder +
|
|
|
|
other_nbr_en->enumsortorder) / 2;
|
|
|
|
|
|
|
|
if (midpoint == nbr_en->enumsortorder ||
|
|
|
|
midpoint == other_nbr_en->enumsortorder)
|
2010-10-25 05:04:37 +02:00
|
|
|
{
|
|
|
|
RenumberEnumType(pg_enum, existing, nelems);
|
|
|
|
/* Clean up and start over */
|
|
|
|
pfree(existing);
|
|
|
|
ReleaseCatCacheList(list);
|
|
|
|
goto restart;
|
|
|
|
}
|
2016-08-31 19:58:01 +02:00
|
|
|
|
|
|
|
newelemorder = midpoint;
|
2010-10-25 05:04:37 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get a new OID for the new label */
|
2014-08-26 04:19:05 +02:00
|
|
|
if (IsBinaryUpgrade)
|
2010-10-25 05:04:37 +02:00
|
|
|
{
|
2014-08-26 04:19:05 +02:00
|
|
|
if (!OidIsValid(binary_upgrade_next_pg_enum_oid))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
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("pg_enum OID value not set when in binary upgrade mode")));
|
2014-08-26 04:19:05 +02:00
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Use binary-upgrade override for pg_enum.oid, if supplied. During
|
|
|
|
* binary upgrade, all pg_enum.oid's are set this way so they are
|
|
|
|
* guaranteed to be consistent.
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
if (neighbor != NULL)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("ALTER TYPE ADD BEFORE/AFTER is incompatible with binary upgrade")));
|
|
|
|
|
|
|
|
newOid = binary_upgrade_next_pg_enum_oid;
|
|
|
|
binary_upgrade_next_pg_enum_oid = InvalidOid;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Normal case: we need to allocate a new Oid for the value.
|
|
|
|
*
|
|
|
|
* We want to give the new element an even-numbered Oid if it's safe,
|
|
|
|
* which is to say it compares correctly to all pre-existing even
|
|
|
|
* numbered Oids in the enum. Otherwise, we must give it an odd Oid.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
bool sorts_ok;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
/* Get a new OID (different from all existing pg_enum tuples) */
|
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
|
|
|
newOid = GetNewOidWithIndex(pg_enum, EnumOidIndexId,
|
|
|
|
Anum_pg_enum_oid);
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Detect whether it sorts correctly relative to existing
|
|
|
|
* even-numbered labels of the enum. We can ignore existing
|
2011-04-10 17:42:00 +02:00
|
|
|
* labels with odd Oids, since a comparison involving one of those
|
|
|
|
* will not take the fast path anyway.
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
sorts_ok = true;
|
|
|
|
for (i = 0; i < nelems; i++)
|
|
|
|
{
|
|
|
|
HeapTuple exists_tup = existing[i];
|
|
|
|
Form_pg_enum exists_en = (Form_pg_enum) GETSTRUCT(exists_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 exists_oid = exists_en->oid;
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
if (exists_oid & 1)
|
|
|
|
continue; /* ignore odd Oids */
|
|
|
|
|
|
|
|
if (exists_en->enumsortorder < newelemorder)
|
|
|
|
{
|
|
|
|
/* should sort before */
|
|
|
|
if (exists_oid >= newOid)
|
|
|
|
{
|
|
|
|
sorts_ok = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* should sort after */
|
|
|
|
if (exists_oid <= newOid)
|
|
|
|
{
|
|
|
|
sorts_ok = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sorts_ok)
|
|
|
|
{
|
|
|
|
/* If it's even and sorts OK, we're done. */
|
|
|
|
if ((newOid & 1) == 0)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* If it's odd, and sorts OK, loop back to get another OID and
|
|
|
|
* try again. Probably, the next available even OID will sort
|
|
|
|
* correctly too, so it's worth trying.
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If it's odd, and does not sort correctly, we're done.
|
|
|
|
* (Probably, the next available even OID would sort
|
|
|
|
* incorrectly too, so no point in trying again.)
|
|
|
|
*/
|
|
|
|
if (newOid & 1)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If it's even, and does not sort correctly, loop back to get
|
|
|
|
* another OID and try again. (We *must* reject this case.)
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Done with info about existing members */
|
|
|
|
pfree(existing);
|
|
|
|
ReleaseCatCacheList(list);
|
|
|
|
|
|
|
|
/* Create the new pg_enum entry */
|
|
|
|
memset(nulls, false, sizeof(nulls));
|
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
|
|
|
values[Anum_pg_enum_oid - 1] = ObjectIdGetDatum(newOid);
|
2010-10-25 05:04:37 +02:00
|
|
|
values[Anum_pg_enum_enumtypid - 1] = ObjectIdGetDatum(enumTypeOid);
|
|
|
|
values[Anum_pg_enum_enumsortorder - 1] = Float4GetDatum(newelemorder);
|
|
|
|
namestrcpy(&enumlabel, newVal);
|
|
|
|
values[Anum_pg_enum_enumlabel - 1] = NameGetDatum(&enumlabel);
|
|
|
|
enum_tup = heap_form_tuple(RelationGetDescr(pg_enum), values, nulls);
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleInsert(pg_enum, enum_tup);
|
2010-10-25 05:04:37 +02:00
|
|
|
heap_freetuple(enum_tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_enum, RowExclusiveLock);
|
2018-10-09 01:51:01 +02:00
|
|
|
|
|
|
|
/* Set up the blacklist hash if not already done in this transaction */
|
|
|
|
if (enum_blacklist == NULL)
|
|
|
|
init_enum_blacklist();
|
|
|
|
|
|
|
|
/* Add the new value to the blacklist */
|
|
|
|
(void) hash_search(enum_blacklist, &newOid, HASH_ENTER, NULL);
|
2010-10-25 05:04:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-09-07 22:11:56 +02:00
|
|
|
/*
|
|
|
|
* RenameEnumLabel
|
|
|
|
* Rename a label in an enum set.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
RenameEnumLabel(Oid enumTypeOid,
|
|
|
|
const char *oldVal,
|
|
|
|
const char *newVal)
|
|
|
|
{
|
|
|
|
Relation pg_enum;
|
|
|
|
HeapTuple enum_tup;
|
|
|
|
Form_pg_enum en;
|
|
|
|
CatCList *list;
|
|
|
|
int nelems;
|
|
|
|
HeapTuple old_tup;
|
|
|
|
bool found_new;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* check length of new label is ok */
|
|
|
|
if (strlen(newVal) > (NAMEDATALEN - 1))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_NAME),
|
|
|
|
errmsg("invalid enum label \"%s\"", newVal),
|
|
|
|
errdetail("Labels must be %d characters or less.",
|
|
|
|
NAMEDATALEN - 1)));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Acquire a lock on the enum type, which we won't release until commit.
|
|
|
|
* This ensures that two backends aren't concurrently modifying the same
|
|
|
|
* enum type. Since we are not changing the type's sort order, this is
|
|
|
|
* probably not really necessary, but there seems no reason not to take
|
|
|
|
* the lock to be sure.
|
|
|
|
*/
|
|
|
|
LockDatabaseObject(TypeRelationId, enumTypeOid, 0, ExclusiveLock);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
pg_enum = table_open(EnumRelationId, RowExclusiveLock);
|
2016-09-07 22:11:56 +02:00
|
|
|
|
|
|
|
/* Get the list of existing members of the enum */
|
|
|
|
list = SearchSysCacheList1(ENUMTYPOIDNAME,
|
|
|
|
ObjectIdGetDatum(enumTypeOid));
|
|
|
|
nelems = list->n_members;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Locate the element to rename and check if the new label is already in
|
|
|
|
* use. (The unique index on pg_enum would catch that anyway, but we
|
|
|
|
* prefer a friendlier error message.)
|
|
|
|
*/
|
|
|
|
old_tup = NULL;
|
|
|
|
found_new = false;
|
|
|
|
for (i = 0; i < nelems; i++)
|
|
|
|
{
|
|
|
|
enum_tup = &(list->members[i]->tuple);
|
|
|
|
en = (Form_pg_enum) GETSTRUCT(enum_tup);
|
|
|
|
if (strcmp(NameStr(en->enumlabel), oldVal) == 0)
|
|
|
|
old_tup = enum_tup;
|
|
|
|
if (strcmp(NameStr(en->enumlabel), newVal) == 0)
|
|
|
|
found_new = true;
|
|
|
|
}
|
|
|
|
if (!old_tup)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("\"%s\" is not an existing enum label",
|
|
|
|
oldVal)));
|
|
|
|
if (found_new)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DUPLICATE_OBJECT),
|
|
|
|
errmsg("enum label \"%s\" already exists",
|
|
|
|
newVal)));
|
|
|
|
|
|
|
|
/* OK, make a writable copy of old tuple */
|
|
|
|
enum_tup = heap_copytuple(old_tup);
|
|
|
|
en = (Form_pg_enum) GETSTRUCT(enum_tup);
|
|
|
|
|
|
|
|
ReleaseCatCacheList(list);
|
|
|
|
|
|
|
|
/* Update the pg_enum entry */
|
|
|
|
namestrcpy(&en->enumlabel, newVal);
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_enum, &enum_tup->t_self, enum_tup);
|
2016-09-07 22:11:56 +02:00
|
|
|
heap_freetuple(enum_tup);
|
|
|
|
|
2019-01-21 19:32:19 +01:00
|
|
|
table_close(pg_enum, RowExclusiveLock);
|
2016-09-07 22:11:56 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-10-09 01:51:01 +02:00
|
|
|
/*
|
|
|
|
* Test if the given enum value is on the blacklist
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
EnumBlacklisted(Oid enum_id)
|
|
|
|
{
|
|
|
|
bool found;
|
|
|
|
|
|
|
|
/* If we've made no blacklist table, all values are safe */
|
|
|
|
if (enum_blacklist == NULL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Else, is it in the table? */
|
|
|
|
(void) hash_search(enum_blacklist, &enum_id, HASH_FIND, &found);
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clean up enum stuff after end of top-level transaction.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
AtEOXact_Enum(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Reset the blacklist table, as all our enum values are now committed.
|
|
|
|
* The memory will go away automatically when TopTransactionContext is
|
|
|
|
* freed; it's sufficient to clear our pointer.
|
|
|
|
*/
|
|
|
|
enum_blacklist = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-10-25 05:04:37 +02:00
|
|
|
/*
|
|
|
|
* RenumberEnumType
|
|
|
|
* Renumber existing enum elements to have sort positions 1..n.
|
|
|
|
*
|
|
|
|
* We avoid doing this unless absolutely necessary; in most installations
|
2013-08-28 19:21:08 +02:00
|
|
|
* it will never happen. The reason is that updating existing pg_enum
|
|
|
|
* entries creates hazards for other backends that are concurrently reading
|
2014-05-06 18:12:18 +02:00
|
|
|
* pg_enum. Although system catalog scans now use MVCC semantics, the
|
2013-08-28 19:21:08 +02:00
|
|
|
* syscache machinery might read different pg_enum entries under different
|
|
|
|
* snapshots, so some other backend might get confused about the proper
|
|
|
|
* ordering if a concurrent renumbering occurs.
|
|
|
|
*
|
|
|
|
* We therefore make the following choices:
|
|
|
|
*
|
|
|
|
* 1. Any code that is interested in the enumsortorder values MUST read
|
|
|
|
* all the relevant pg_enum entries with a single MVCC snapshot, or else
|
|
|
|
* acquire lock on the enum type to prevent concurrent execution of
|
|
|
|
* AddEnumLabel().
|
|
|
|
*
|
|
|
|
* 2. Code that is not examining enumsortorder can use a syscache
|
|
|
|
* (for example, enum_in and enum_out do so).
|
2010-10-25 05:04:37 +02:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
RenumberEnumType(Relation pg_enum, HeapTuple *existing, int nelems)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We should only need to increase existing elements' enumsortorders,
|
|
|
|
* never decrease them. Therefore, work from the end backwards, to avoid
|
|
|
|
* unwanted uniqueness violations.
|
|
|
|
*/
|
|
|
|
for (i = nelems - 1; i >= 0; i--)
|
|
|
|
{
|
|
|
|
HeapTuple newtup;
|
|
|
|
Form_pg_enum en;
|
|
|
|
float4 newsortorder;
|
|
|
|
|
|
|
|
newtup = heap_copytuple(existing[i]);
|
|
|
|
en = (Form_pg_enum) GETSTRUCT(newtup);
|
|
|
|
|
|
|
|
newsortorder = i + 1;
|
|
|
|
if (en->enumsortorder != newsortorder)
|
|
|
|
{
|
|
|
|
en->enumsortorder = newsortorder;
|
|
|
|
|
2017-01-31 22:42:24 +01:00
|
|
|
CatalogTupleUpdate(pg_enum, &newtup->t_self, newtup);
|
2010-10-25 05:04:37 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
heap_freetuple(newtup);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Make the updates visible */
|
|
|
|
CommandCounterIncrement();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* qsort comparison function for tuples by sort order */
|
|
|
|
static int
|
|
|
|
sort_order_cmp(const void *p1, const void *p2)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
HeapTuple v1 = *((const HeapTuple *) p1);
|
|
|
|
HeapTuple v2 = *((const HeapTuple *) p2);
|
|
|
|
Form_pg_enum en1 = (Form_pg_enum) GETSTRUCT(v1);
|
|
|
|
Form_pg_enum en2 = (Form_pg_enum) GETSTRUCT(v2);
|
2010-10-25 05:04:37 +02:00
|
|
|
|
|
|
|
if (en1->enumsortorder < en2->enumsortorder)
|
|
|
|
return -1;
|
|
|
|
else if (en1->enumsortorder > en2->enumsortorder)
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
2018-10-09 01:51:01 +02:00
|
|
|
|
|
|
|
Size
|
|
|
|
EstimateEnumBlacklistSpace(void)
|
|
|
|
{
|
|
|
|
size_t entries;
|
|
|
|
|
|
|
|
if (enum_blacklist)
|
|
|
|
entries = hash_get_num_entries(enum_blacklist);
|
|
|
|
else
|
|
|
|
entries = 0;
|
|
|
|
|
|
|
|
/* Add one for the terminator. */
|
|
|
|
return sizeof(Oid) * (entries + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
SerializeEnumBlacklist(void *space, Size size)
|
|
|
|
{
|
|
|
|
Oid *serialized = (Oid *) space;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure the hash table hasn't changed in size since the caller
|
|
|
|
* reserved the space.
|
|
|
|
*/
|
|
|
|
Assert(size == EstimateEnumBlacklistSpace());
|
|
|
|
|
|
|
|
/* Write out all the values from the hash table, if there is one. */
|
|
|
|
if (enum_blacklist)
|
|
|
|
{
|
|
|
|
HASH_SEQ_STATUS status;
|
|
|
|
Oid *value;
|
|
|
|
|
|
|
|
hash_seq_init(&status, enum_blacklist);
|
|
|
|
while ((value = (Oid *) hash_seq_search(&status)))
|
|
|
|
*serialized++ = *value;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write out the terminator. */
|
|
|
|
*serialized = InvalidOid;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure the amount of space we actually used matches what was
|
|
|
|
* estimated.
|
|
|
|
*/
|
|
|
|
Assert((char *) (serialized + 1) == ((char *) space) + size);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
RestoreEnumBlacklist(void *space)
|
|
|
|
{
|
|
|
|
Oid *serialized = (Oid *) space;
|
|
|
|
|
|
|
|
Assert(!enum_blacklist);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* As a special case, if the list is empty then don't even bother to
|
|
|
|
* create the hash table. This is the usual case, since enum alteration
|
|
|
|
* is expected to be rare.
|
|
|
|
*/
|
|
|
|
if (!OidIsValid(*serialized))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Read all the values into a new hash table. */
|
|
|
|
init_enum_blacklist();
|
|
|
|
do
|
|
|
|
{
|
|
|
|
hash_search(enum_blacklist, serialized++, HASH_ENTER, NULL);
|
|
|
|
} while (OidIsValid(*serialized));
|
|
|
|
}
|