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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
