Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

> At Wed, 28 Nov 2018 14:41:40 +0900, Tatsuro Yamada <yamada(dot)tatsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <54bd214b-d0d3-8654->>>>
>>>> * tab_completion_alter_index_set_statistics.patch
>>>> =======
>>>> There are two problems. You can use these DDL before testing.
>>>> #create table hoge (a integer, b integer);
>>>> #create index ind_hoge on hoge (a, (a + b), (a * b));
>>>>
>>>> 1) Can't get column names
>>>>
>>>> # alter index ind_hoge alter column <tab!><tab!>... but can't
>>>> # complete.
>>> Currently the only continueable rule to the rule is SET
>>> STATISTICS so we usually expect the number of an expression
>>> column there. Even though we actually name every expression
>>> column in an index, users hardly see the names. The names are in
>>> the index column number order in your example, but what if the
>>> name of the first column were 'foo'?
>>> =# alter index ind_hoge2 alter column
>>> expr expr1 foo
>>> We could still *guess* what is expr or exrp1 but I don't think it
>>> helps much. (Note: foo is not usable in this context as it's a
>>> non-expression column.)
>>
>> Thanks for your comment.
>> We can get column name by using "\d index_name" like this:
>>
>> # \d ind_hoge
>> Index "public.ind_hoge"
>> Column | Type | Key? | Definition
>> --------+---------+------+------------
>> a | integer | yes | a
>> expr | integer | yes | (a + b)
>> expr1 | integer | yes | (a * b)
>> btree, for table "public.hoge"
>>
>> So, I suppose that it's easy to understand what column is an
>> expression column.
>
> Yeah, actually we can find them there, but I don't think it's
> popular. I suppose that most of people are unconcious of the
> names since they didn't named them. Moreover what makes me
> uneasy with this is that it doesn't suggest attribute numbers,
> which are firstly expected there. But anyway it is impossible
> with readline since suggestions are sorted as strings. ("1",
> "11", "12", "2" order, I don't think indexes often have that many
> columns, though.)

Okay, I understand.

- For now, there is no column_number column on "\d index_name" result.
So, if tab-completion suggested column_numbers, user can't match these easily.

- Suggested column_name and column_number are sorted as a string by readline.
These are an unnatural. But this is another topic on this thread.

Example:
# alter index ind_hoge alter column <tab!>
c expr expr1 expr10 expr11 expr2 expr3 expr4 expr5 expr6 expr7 expr8 expr9

>> Of course, user will get syntax error if user chose "a" column like a
>> "foo" which is
>> non-expression column as you mentioned.
>> Probably, I will be able to fix the patch to get only expression
>> columns from the index.
>> Should I do that?
>
> Nope. That's just too-much. We are already showing unusable
> suggestions in other places, for example, exiting tables for
> CREATE TABLE. (It is useful for me as it suggests what should be
> placed there.)

I see.

>> I prefer to use column name instead column number because
>> there is no column number on \d index_name and \d+ index_name.
>
> Some people prefer names even if they are implicitly
> given. Others (including myself) prefer numbers.

So, we should better to vote to decide implementation of the tab-completion.

Which is better to use either column_names or column_numbers?
I'd like to hear opinions from others. :)

>>>> 2) I expected column names for column numbers after "SET STATISTICS",
>>>> but
>>>> tab-completion gave schema names
>>>>
>>>> # alter index ind_hoge alter column expr SET STATISTICS <tab!>
>>>> information_schema. pg_catalog. pg_temp_1. pg_toast.
>>>> pg_toast_temp_1. public.
>>> This is the result of STATISTICS <things> completion. SET
>>> STATISTICS always doesn't take statistics name so this is safe.
>>
>> :)
>
> So I think it is reasonable.

Thanks.

Regards,
Tatsuro Yamada