Richard Broersma <richard.broersma@xxxxxxxxx> writes:
> On Mon, Dec 27, 2010 at 12:50 PM, InterRob <rob.marjot@xxxxxxxxx> wrote:
>> pgsql Command "\d test" produces the following:
>> Table "public.test"
>> Column | Type | Modifiers
>> ------------+---------+-----------
>> object_id | integer |
>> subject_id | integer |
>> Indexes:
>> "EXCL_double_combi" EXCLUDE USING btree (imm_least(subject_id,
>> object_id) WITH =, imm_greatest(subject_id, object_id) WITH =)
> I see. Since exclusion constraints is a rather new feature, psql may
> need some tweaking to report these constraints as constraints
No, the behavior is entirely intentional. Compare what it's always been
for primary keys:
regression=# create table foo (f1 int primary key);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
CREATE TABLE
regression=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer | not null
Indexes:
"foo_pkey" PRIMARY KEY, btree (f1)
regression=#
BTW, I fail to see the point of using EXCLUDE in this particular way.
You'd get the same results, more efficiently, with a plain UNIQUE
constraint on the two function expressions. EXCLUDE is really only
interesting for cases where the behavior you want doesn't conform to
btree semantics.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
