Re: SET CONSTRAINTS todo

I wanted to work on this todo item and I have a few questions about the semantics of it. Essentially, it is not possible to have more than one relname for a constraint, even though the comment in trigger.c says otherwise. I have used this code to test this:

<<<
CREATE TABLE products (
product_no integer CONSTRAINT must_be_different UNIQUE DEFERRABLE,
name text,
price numeric
);

CREATE TABLE products2 (
product_no integer CONSTRAINT must_be_different UNIQUE DEFERRABLE,
name text,
price numeric
);
>>>

which results in the following error:

<<<
ERROR: relation "must_be_different" already exists
>>>

Therefore prefixing them with a table name does not seem to make sense. Additionally, there is already the feature of prefixing the constraint relname with a schema to limit the search space.

Is the intention of the todo to allow the user to specify a tablename which limits the search path to that table's schema or is the feature to extend constraints to allow per table naming. In other words, would the feature allow multiple constraints of the same name in a schema since they would be table specific?

--Dan

I see what went wrong in my example. Unique constraints must have unique names since they create an index. I'll try again, sorry for the noise.

--Dan

Dan Colish <dcolish(at)gmail(dot)com> writes:
> I wanted to work on this todo item and I have a few questions about
> the semantics of it. Essentially, it is not possible to have more than
> one relname for a constraint,

That is per SQL spec: SQL92 10.6 syntax rule 2 saith

2) The <qualified identifier> of <constraint name> shall be differ-
ent from the <qualified identifier> of the <constraint name> of
any other constraint defined in the same schema.

I believe we are already laxer than the spec, because we don't enforce
that restriction except for index-based constraints. I'm not terribly
excited about trying to make it weaker yet.

> Is the intention of the todo to allow the user to specify a tablename
> which limits the search path to that table's schema or is the feature to
> extend constraints to allow per table naming.

I think the TODO item you're looking at is just about how narrowly you
can specify the target(s) of a SET CONSTRAINTS command. It's not meant
to say anything about what constraint names can be created in the first
place.

regards, tom lane