On Wed, Jan 13, 2021 at 1:55 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Tue, Jan 12, 2021 at 11:09 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 10:00 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > 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?
> >
> > 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/
