needs to check the new constraint against columns of derived domains too.
Also, make it error out if the domain to be modified is used within any
composite-type columns. Eventually we should support that case, but it seems
a bit painful, and not suitable for a back-patch. For the moment just let the
user know we can't do it.
Backpatch to 8.2, which is the only released version that allows nested
domains. Possibly the other part should be back-patched further.
</para>
</refsect1>
+ <refsect1>
+ <title>Notes</title>
+
+ <para>
+ Currently, <command>ALTER DOMAIN ADD CONSTRAINT</> and
+ <command>ALTER DOMAIN SET NOT NULL</> will fail if the named domain or
+ any derived domain is used within a composite-type column of any
+ table in the database. They should eventually be improved to be
+ able to verify the new constraint for such nested columns.
+ </para>
+
+ </refsect1>
+
<refsect1>
<title>Examples</title>
AlterTableCmd *cmd, bool recurse);
static void ATOneLevelRecursion(List **wqueue, Relation rel,
AlterTableCmd *cmd);
-static void find_composite_type_dependencies(Oid typeOid,
- const char *origTblName);
static void ATPrepAddColumn(List **wqueue, Relation rel, bool recurse,
AlterTableCmd *cmd);
static void ATExecAddColumn(AlteredTableInfo *tab, Relation rel,
*/
if (newrel)
find_composite_type_dependencies(oldrel->rd_rel->reltype,
- RelationGetRelationName(oldrel));
+ RelationGetRelationName(oldrel),
+ NULL);
/*
* Generate the constraint and default execution states
/*
* find_composite_type_dependencies
*
- * Check to see if a table's rowtype is being used as a column in some
+ * Check to see if a composite type is being used as a column in some
* other table (possibly nested several levels deep in composite types!).
* Eventually, we'd like to propagate the check or rewrite operation
* into other such tables, but for now, just error out if we find any.
*
+ * Caller should provide either a table name or a type name (not both) to
+ * report in the error message, if any.
+ *
* We assume that functions and views depending on the type are not reasons
* to reject the ALTER. (How safe is this really?)
*/
-static void
-find_composite_type_dependencies(Oid typeOid, const char *origTblName)
+void
+find_composite_type_dependencies(Oid typeOid,
+ const char *origTblName,
+ const char *origTypeName)
{
Relation depRel;
ScanKeyData key[2];
if (rel->rd_rel->relkind == RELKIND_RELATION)
{
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("cannot alter table \"%s\" because column \"%s\".\"%s\" uses its rowtype",
- origTblName,
- RelationGetRelationName(rel),
- NameStr(att->attname))));
+ if (origTblName)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("cannot alter table \"%s\" because column \"%s\".\"%s\" uses its rowtype",
+ origTblName,
+ RelationGetRelationName(rel),
+ NameStr(att->attname))));
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("cannot alter type \"%s\" because column \"%s\".\"%s\" uses it",
+ origTypeName,
+ RelationGetRelationName(rel),
+ NameStr(att->attname))));
}
else if (OidIsValid(rel->rd_rel->reltype))
{
* recursively check for indirect dependencies via its rowtype.
*/
find_composite_type_dependencies(rel->rd_rel->reltype,
- origTblName);
+ origTblName, origTypeName);
}
relation_close(rel, AccessShareLock);
* the domain type. We have opened each rel and acquired the specified lock
* type on it.
*
+ * We support nested domains by including attributes that are of derived
+ * domain types. Current callers do not need to distinguish between attributes
+ * that are of exactly the given domain and those that are of derived domains.
+ *
* XXX this is completely broken because there is no way to lock the domain
* to prevent columns from being added or dropped while our command runs.
* We can partially protect against column drops by locking relations as we
* trivial risk of deadlock. We can minimize but not eliminate the deadlock
* risk by using the weakest suitable lock (ShareLock for most callers).
*
- * XXX to support domains over domains, we'd need to make this smarter,
- * or make its callers smarter, so that we could find columns of derived
- * domains. Arrays of domains would be a problem too.
+ * XXX the API for this is not sufficient to support checking domain values
+ * that are inside composite types or arrays. Currently we just error out
+ * if a composite type containing the target domain is stored anywhere.
+ * There are not currently arrays of domains; if there were, we could take
+ * the same approach, but it'd be nicer to fix it properly.
*
* Generally used for retrieving a list of tests when adding
* new constraints to a domain.
Form_pg_attribute pg_att;
int ptr;
- /* Ignore dependees that aren't user columns of relations */
+ /* Check for directly dependent types --- must be domains */
+ if (pg_depend->classid == TypeRelationId)
+ {
+ Assert(get_typtype(pg_depend->objid) == 'd');
+ /*
+ * Recursively add dependent columns to the output list. This
+ * is a bit inefficient since we may fail to combine RelToCheck
+ * entries when attributes of the same rel have different derived
+ * domain types, but it's probably not worth improving.
+ */
+ result = list_concat(result,
+ get_rels_with_domain(pg_depend->objid,
+ lockmode));
+ continue;
+ }
+
+ /* Else, ignore dependees that aren't user columns of relations */
/* (we assume system columns are never of domain types) */
if (pg_depend->classid != RelationRelationId ||
pg_depend->objsubid <= 0)
/* Acquire requested lock on relation */
rel = relation_open(pg_depend->objid, lockmode);
- /* It could be a view or composite type; if so ignore it */
+ /*
+ * Check to see if rowtype is stored anyplace as a composite-type
+ * column; if so we have to fail, for now anyway.
+ */
+ if (OidIsValid(rel->rd_rel->reltype))
+ find_composite_type_dependencies(rel->rd_rel->reltype,
+ NULL,
+ format_type_be(domainOid));
+
+ /* Otherwise we can ignore views, composite types, etc */
if (rel->rd_rel->relkind != RELKIND_RELATION)
{
relation_close(rel, lockmode);
extern void renamerel(Oid myrelid,
const char *newrelname);
+extern void find_composite_type_dependencies(Oid typeOid,
+ const char *origTblName,
+ const char *origTypeName);
+
extern AttrNumber *varattnos_map(TupleDesc old, TupleDesc new);
extern AttrNumber *varattnos_map_schema(TupleDesc old, List *schema);
extern void change_varattnos_of_a_node(Node *node, const AttrNumber *newattno);
1
(1 row)
+-- Check that ALTER DOMAIN tests columns of derived types
+create domain posint as int4;
+-- Currently, this doesn't work for composite types, but verify it complains
+create type ddtest1 as (f1 posint);
+create table ddtest2(f1 ddtest1);
+insert into ddtest2 values(row(-1));
+alter domain posint add constraint c1 check(value >= 0);
+ERROR: cannot alter type "posint" because column "ddtest2"."f1" uses it
+drop table ddtest2;
+alter domain posint add constraint c1 check(value >= 0);
+create domain posint2 as posint check (value % 2 = 0);
+create table ddtest2(f1 posint2);
+insert into ddtest2 values(11); -- fail
+ERROR: value for domain posint2 violates check constraint "posint2_check"
+insert into ddtest2 values(-2); -- fail
+ERROR: value for domain posint2 violates check constraint "c1"
+insert into ddtest2 values(2);
+alter domain posint add constraint c2 check(value >= 10); -- fail
+ERROR: column "f1" of table "ddtest2" contains values that violate the new constraint
+alter domain posint add constraint c2 check(value > 0); -- OK
+drop table ddtest2;
+drop type ddtest1;
+drop domain posint cascade;
+NOTICE: drop cascades to type posint2
select doubledecrement(1); -- fail at assignment to v
select doubledecrement(2); -- fail at return
select doubledecrement(3); -- good
+
+-- Check that ALTER DOMAIN tests columns of derived types
+
+create domain posint as int4;
+
+-- Currently, this doesn't work for composite types, but verify it complains
+create type ddtest1 as (f1 posint);
+create table ddtest2(f1 ddtest1);
+insert into ddtest2 values(row(-1));
+alter domain posint add constraint c1 check(value >= 0);
+drop table ddtest2;
+
+alter domain posint add constraint c1 check(value >= 0);
+
+create domain posint2 as posint check (value % 2 = 0);
+create table ddtest2(f1 posint2);
+insert into ddtest2 values(11); -- fail
+insert into ddtest2 values(-2); -- fail
+insert into ddtest2 values(2);
+
+alter domain posint add constraint c2 check(value >= 10); -- fail
+alter domain posint add constraint c2 check(value > 0); -- OK
+
+drop table ddtest2;
+drop type ddtest1;
+drop domain posint cascade;
projects / users / bernd / postgres.git / commitdiff