On Wed, Jan 13, 2021 at 1:55 PM Fujii Masao <masao.fu...@gmail.com> wrote: > > On Tue, Jan 12, 2021 at 11:09 AM Fujii Masao <masao.fu...@gmail.com> wrote: > > > > On Tue, Jan 12, 2021 at 10:00 AM Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > > > > > > On Mon, Jan 11, 2021 at 11:00 PM Peter Eisentraut > > > <peter.eisentr...@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? > > > > IMO yes because it's less confusing to make the document and > > tab-completion consistent.
Agreed. > > I updated the patch that way. Could you review this version? Thank you for updating the patch. Looks good to me. Regards, -- Masahiko Sawada EnterpriseDB: https://www.enterprisedb.com/