Re: WIP: generalized index constraints
От | Jeff Davis |
---|---|
Тема | Re: WIP: generalized index constraints |
Дата | |
Msg-id | 1250827466.21841.105.camel@jdavis обсуждение исходный текст |
Ответ на | Re: WIP: generalized index constraints (Brendan Jurd <direvus@gmail.com>) |
Ответы |
Re: WIP: generalized index constraints
Re: WIP: generalized index constraints |
Список | 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
В списке pgsql-hackers по дате отправления: