Re: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion
Дата
Msg-id CAD21AoBf8fUg7MvBAau2wsEKOTMgpgJmneOJCbt4=4ba1hc_EA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Mon, Jan 11, 2021 at 11:00 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 2021-01-05 10:56, Masahiko Sawada wrote:
> > BTW according to the documentation, the options of DECLARE statement
> > (BINARY, INSENSITIVE, SCROLL, and NO SCROLL) are order-sensitive.
> >
> > DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ]
> >      CURSOR [ { WITH | WITHOUT } HOLD ] FOR query
> >
> > But I realized that these options are actually order-insensitive. For
> > instance, we can declare a cursor like:
> >
> > =# declare abc scroll binary cursor for select * from pg_class;
> > DECLARE CURSOR
> >
> > The both parser code and documentation has been unchanged from 2003.
> > Is it a documentation bug?
>
> According to the SQL standard, the ordering of the cursor properties is
> fixed.  Even if the PostgreSQL parser offers more flexibility, I think
> we should continue to encourage writing the clauses in the standard order.

Thanks for your comment. Agreed.

So regarding the tab completion for DECLARE statement, perhaps it
would be better to follow the documentation? In the current proposed
patch, we complete it with the options in any order.

Regards,

-- 
Masahiko Sawada
EnterpriseDB:  https://www.enterprisedb.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Keisuke Kuroda
Дата:
Сообщение: Re: Huge memory consumption on partitioned table with FKs
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: libpq compression