Re: Ticket 119: handling opclass in dlgIndex

[Dave Page <dpage(at)pgadmin(dot)org>]

On Wed, Dec 23, 2009 at 3:45 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> Hi,
>
> This patch adds a combobox in dlgIndex to allow a user to change the
> operator class for each column. I added a new column in the columns's
> list to show the non default opclass.
>
> Comments?

Seems to be some (long standing) inconsistency in our capitalisation
of multi-word labels - eg.

     lstColumns->AddColumn(_("Column name"), 90);
     lstColumns->AddColumn(_("Order"), 40);
     lstColumns->AddColumn(_("NULLs Order"), 50);
+    lstColumns->AddColumn(_("Op. Class"), 40);

"Column name" vs. NULLs Order" for example.

I suspect you should remove this too:

+        wxLogError(wxT("opclass:") + GetOperatorClasses());

> BTW, I was wondering why the index's type is not set to btree by
> default. It is set to "", which really means btree. But the opclass code
> and the ASC/DESC and NULL FIRST/LAST code treat it as non btree, which
> is weird. I wonder if we can delete the blank type option.

Don't see why not.

> Another question. There is right now no way to change an index. We can
> alter its name, tablespace, stuff like that. But we can't really change
> its definition. I wonder if there would be a way to allow someone to
> change it with first dropping the old object and creating the new one.
> That would be better, for the user, than to make him drop the index and
> then recreate it completely. Not sure that my explanation is really clear :)

We'd really need an implementation of CREATE OR REPLACE INDEX ...
CONCURRENTLY to do that well I think. Otherwise, we could
inadvertently cause users great pain if they don't realise a
drop/create will happen for certain changes.


-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com