Skip site navigation (1) Skip section navigation (2)

Re: Ticket 119: handling opclass in dlgIndex

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Ticket 119: handling opclass in dlgIndex
Date: 2009-12-23 18:08:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
Le 23/12/2009 17:47, Dave Page a écrit :
> 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 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


In response to


pgadmin-hackers by date

Next:From: Dave PageDate: 2009-12-23 19:04:13
Subject: Re: Ticket 119: handling opclass in dlgIndex
Previous:From: Dave PageDate: 2009-12-23 16:47:52
Subject: Re: Ticket 119: handling opclass in dlgIndex

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group