>+#define Query_for_list_of_cursors \
>+" SELECT name FROM pg_cursors"\
>
>This query should be the following?
>
>" SELECT pg_catalog.quote_ident(name) "\
>" FROM pg_catalog.pg_cursors "\
>" WHERE substring(pg_catalog.quote_ident(name),1,%d)='%s'"
>
>+/* CLOSE */
>+ else if (Matches("CLOSE"))
>+ COMPLETE_WITH_QUERY(Query_for_list_of_cursors
>+ " UNION ALL SELECT 'ALL'");
>
>"UNION ALL" should be "UNION"?
Thank you for your advice, and I corrected them.
>> + COMPLETE_WITH_QUERY(Query_for_list_of_cursors
>> + " UNION SELECT 'ABSOLUTE'"
>> + " UNION SELECT 'BACKWARD'"
>> + " UNION SELECT 'FORWARD'"
>> + " UNION SELECT 'RELATIVE'"
>> + " UNION SELECT 'ALL'"
>> + " UNION SELECT 'NEXT'"
>> + " UNION SELECT 'PRIOR'"
>> + " UNION SELECT 'FIRST'"
>> + " UNION SELECT 'LAST'"
>> + " UNION SELECT 'FROM'"
>> + " UNION SELECT 'IN'");
>>
>> This change makes psql unexpectedly output "FROM" and "IN" just after "FETCH".
>
>I think "FROM" and "IN" can be placed just after "FETCH". According to
>the documentation, the direction can be empty. For instance, we can do
>like:
Thank you!
>I've attached the patch improving the tab completion for DECLARE as an
>example. What do you think?
>
>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?
Thank you for your patch, and it is good.
I cannot find the description "(BINARY, INSENSITIVE, SCROLL, and NO SCROLL) are order-sensitive."
I saw "The key words BINARY, INSENSITIVE, and SCROLL can appear in any order." , according to the documentation.
I made a new patch, but the amount of codes was large due to order-insensitive.
If you know of a better way, please let me know.
Regards,
Shinya Kato
