Postgres Pro
Downloads
Home   >   mailing lists

Thread: Unique constraints

Unique constraints

From
"Dave Page"
Date:
Hi Guys,

In PostgreSQL 7.2, unique constraints were just indexes. In 7.3 however,
it knows they are constraints and thus will not allow you to simply drop
the index.

Should we add an extra object type under pgTable to contain such indexes
or can anyone think of a better solution?

Regards, Dave.

Re: Unique constraints

From
Andreas Pflug
Date:
Dave Page wrote:

>Hi Guys,
>
>In PostgreSQL 7.2, unique constraints were just indexes. In 7.3 however,
>it knows they are constraints and thus will not allow you to simply drop
>the index.
>
>Should we add an extra object type under pgTable to contain such indexes
>or can anyone think of a better solution?
>
>
>
Maybe we should reorganize the tree like this:

Tables
    tableFoo
       Columns
          col1
          col2
          col3
       Constraints
          pk_tableFoo
          fk_refToBar
          chk_range
          unq_col3
       Indexes
          idx_one
          idx_two_unq_non_constr
       Rules
       Triggers

I'd like to have less collections under <table>, since most of them have
few members and consume precious screen space.

Regards,
Andreas

Re: Unique constraints

From
"Dave Page"
Date:
It's rumoured that Andreas Pflug once said:
> Dave Page wrote:
>
>>Hi Guys,
>>
>>In PostgreSQL 7.2, unique constraints were just indexes. In 7.3
>>however, it knows they are constraints and thus will not allow you to
>>simply drop the index.
>>
>>Should we add an extra object type under pgTable to contain such
>>indexes or can anyone think of a better solution?
>>
>>
>>
> Maybe we should reorganize the tree like this:
>
> Tables
>    tableFoo
>       Columns
>          col1
>          col2
>          col3
>       Constraints
>          pk_tableFoo
>          fk_refToBar
>          chk_range
>          unq_col3
>       Indexes
>          idx_one
>          idx_two_unq_non_constr
>       Rules
>       Triggers
>
> I'd like to have less collections under <table>, since most of them
> have  few members and consume precious screen space.

Yes, that does sound cleaner, though I'm not sure about including the
primary key as we can't do anything to it. Having said that though, it
would give a nice view of all the member columns...
Regards, Dave