Re: PATCH: psql tab completion for SELECT - Mailing list pgsql-hackers

From Edmund Horner
Subject Re: PATCH: psql tab completion for SELECT
Date
Msg-id CAMyN-kAJX9fkzm1aFE5sp4se9t1c+p1e1JJGc_MXerxHUK9qoQ@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: psql tab completion for SELECT  (Andres Freund <andres@anarazel.de>)
Responses Re: PATCH: psql tab completion for SELECT
List pgsql-hackers
On 15 January 2018 at 15:45, Andres Freund <andres@anarazel.de> wrote:
> On January 14, 2018 5:44:01 PM PST, Edmund Horner <ejrh00@gmail.com> wrote:
>>In psql if you have readline support and press TAB, psql will often
>>run a DB query to get a list of possible completions to type on your
>>current command line.
>>
>>It uses the current DB connection for this, which means that if the
>>tab completion query fails (e.g. because psql is querying catalog
>>objects that doesn't exist in your server), the current transaction
>>(if any) fails.  An example of this happening is:
>
> Ah, that's what I thought. I don't think this is the right fix.
>
>
>> pg_subscription table doesn't
>>exist on 9.2!  User realises their mistake and types a different
>>command)
>>
>>    postgres=# select  * from foo;
>>    ERROR:  current transaction is aborted, commands ignored until end
>>of transaction block
>
> All worries like this are supposed to check the server version.

In psql there are around 200 such tab completion queries, none of
which checks the server version.  Many would cause the user's
transaction to abort if invoked on an older server.  Identifying the
appropriate server versions for each one would be quite a bit of work.

Is there a better way to make this more robust?


pgsql-hackers by date:

Previous
From: Nikolay Shaplov
Date:
Subject: Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] GnuTLS support