Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS - Mailing list pgsql-hackers

> At Wed, 28 Nov 2018 14:41:40 +0900, Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.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