Re: [HACKERS] SET CONSTRAINTS todo
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SET CONSTRAINTS todo
Dan Colish dcol...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
