Sorry for not being on top of this. On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote: > > ... If that's the only issue then I don't see any need to wait on > > the author, so will take this one. > > I find myself quite dissatisfied with the way that this patch adds yet > another bool flag to index_create (which has too many of those already), > with the effect of causing it to exactly *not* do an index creation. > That's a clear violation of the principle of least astonishment IMNSHO. > I think what's needed here is to refactor things a bit so that the > constraint-creation code is pulled out of index_create and called > separately where needed. Hacking on that now. > Thanks. One other issue that might be worthy of discussion is that as things > stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause > the constraint to absorb the index as an INTERNAL dependency. That > means dropping the constraint would make the index go away silently --- > it no longer has any separate life. If the intent is just to provide a > way to get the effect of ALTER ADD PRIMARY KEY CONCURRENTLY, then this > behavior is probably fine. But someone who believes DROP CONSTRAINT > exactly reverses the effects of ADD CONSTRAINT might be surprised. > Comments? > Since we rename the index automatically to match the constraint name, implying that the index now belongs to the system, I think the user should expect the index to go away with the constraint; else we have to remember index's original name and restore that name on DROP CONSTRAINT, which IMHO will be even more unintuitive. Regards, -- gurjeet.singh @ EnterpriseDB - The Enterprise Postgres Company http://www.EnterpriseDB.com singh.gurjeet@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
