From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Brendan Jurd <direvus(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP: generalized index constraints |
Date: | 2009-08-21 04:04:26 |
Message-ID: | 1250827466.21841.105.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2009-08-21 at 12:23 +1000, Brendan Jurd wrote:
> This may be an opportunity to fix it.
>
> The current behaviour seems to be predicated on the unique constraint
> being an integral part of the index itself. While this might be true
> from a system catalog point of view (pg_index.indisunique), if a user
> says that they want to copy a table's structure INCLUDING INDEXES
> EXCLUDING CONSTRAINTS then IMO they've made their intention perfectly
> clear. They'd expect it to create an index sans the unique
> constraint. Ignoring the user's intention and copying the index as-is
> (including the unique constraint) would be unfriendly.
I don't have strong feelings either way. I think that's probably a
separate patch, and a fairly small patch.
Using the principle of least surprise, if a user specified one of
INDEXES or CONSTRAINTS, but not both, and there is a unique index, we
should raise an ERROR (or at least a WARNING).
There is not much of a problem with backwards compatibility. LIKE is
shorthand (not stored in catalogs), so it doesn't affect
pg_dump/restore. And hopefully there aren't a lot of apps out there
creating tables dynamically using the LIKE syntax.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-08-21 04:18:52 | Re: Multi-pass planner |
Previous Message | Greg Stark | 2009-08-21 03:08:33 | Re: WIP: generalized index constraints |