Re: Ticket 119: handling opclass in dlgIndex

Le 23/12/2009 17:47, Dave Page a écrit :
> On Wed, Dec 23, 2009 at 3:45 PM, Guillaume Lelarge
> <guillaume@lelarge.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 don't really know what the english standard way of casing words is. I
know that, in French, you're supposed to put the first character of a
string in uppercase. In English, I suppose I need to put the first
character of each word in uppercase. So, I think we need to upper case
the n in "Column name" (ie, "Column Name"). Can you confirm?

> I suspect you should remove this too:
>
> +        wxLogError(wxT("opclass:") + GetOperatorClasses());
>

Damn, I deleted one just before sending the patch. Obviously I forgot
this one.

>> 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.
>

Will do. Should it be in another patch?

>> 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.
>

Or we have to tell them we need to drop and create their index when they
click the OK button, perhaps giving them the choice to do it
concurrently. I wonder if there are other objects that would need that
treatment.


--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com