From: Tom Lane <tgl@sss.pgh.pa.us>
To: Edmund Horner <ejrh00@gmail.com>
cc: Vik Fearing <vik.fearing@2ndquadrant.com>,
        Andres Freund <andres@anarazel.de>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: PATCH: psql tab completion for SELECT
In-reply-to: 
 <CAMyN-kDJk01k=qKRHA-SKBBbdmTcJ4fyehjLc_N0CTCm4NdA2Q@mail.gmail.com>
References: 
 <CAMyN-kB_xrU4iYdcF1j=tijgO1DSyjtb3j96O4UEj91XZrZcMg@mail.gmail.com>
 <CAMyN-kCr6aUFaE=ov+_r=b4nS_ihtmJ8-MLMoomZGWdNFgMaVw@mail.gmail.com>
 <F9466A55-8F16-4DC2-BAE8-6386870A3C3C@anarazel.de>
 <CAMyN-kC65Xdn3Y5A+muYWMAR50gk-oCABcyZ809wuV0x9_nsJQ@mail.gmail.com>
 <882D6617-FA16-4C56-8FE0-884BCBBE5A4C@anarazel.de>
 <CAMyN-kAJX9fkzm1aFE5sp4se9t1c+p1e1JJGc_MXerxHUK9qoQ@mail.gmail.com>
 <2738.1516234038@sss.pgh.pa.us>
 <3a919958-e508-3b66-686f-44a7937fb6e7@2ndquadrant.com>
 <CAMyN-kDBXUAmoRb1oYaSMQDUA3=xccEzQncRBMywt4KodPdwTw@mail.gmail.com>
 <cbd1e86b-88c9-edc1-8a88-66df58d8cd39@2ndquadrant.com>
 <CAMyN-kBY=cPuD-LXTZndS6biWDYUMScd8N=vGeArPU+bztP5VA@mail.gmail.com>
 <24314.1520190408@sss.pgh.pa.us>
 <CAMyN-kDJk01k=qKRHA-SKBBbdmTcJ4fyehjLc_N0CTCm4NdA2Q@mail.gmail.com>
Comments: In-reply-to Edmund Horner <ejrh00@gmail.com>
	message dated "Mon, 05 Mar 2018 23:21:28 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10991.1520260903.1@sss.pgh.pa.us>
Date: Mon, 05 Mar 2018 09:41:43 -0500
Message-ID: <10992.1520260903@sss.pgh.pa.us>
Precedence: bulk

Edmund Horner <ejrh00@gmail.com> writes:
> On 5 March 2018 at 08:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If people like this approach, I propose to commit this more or less
>> as-is.  The select-tab-completion patch would then need to be rewritten
>> to use this infrastructure, but I think that should be straightforward.

> My patch had 4 versions: PRE_81, PRE_90, PRE_96, and current.  This
> could be reformulated as
>     static const VersionedQuery
> Query_for_list_of_selectable_functions_or_attributes[] = {
>         {90600, ... },
>         {90000, ... },
>         {80100, ... },
>         {70300, ... },
>         {0, NULL}
>     };

Right.

> Is it overkill to have so many variations?

Well, it's whatever you need for the purpose.  We could discuss what the
support cutoff is, but I doubt we'd make it any later than 8.0, so some
types of catalog queries are going to need a lot of variations.

> I am still just slightly unclear on where we are in relation to the
> SAVEPOINT patch -- is that redundant now?

I'm inclined to think it's a bit pointless, if the direction we're
heading is to make the queries actually work on every server version.
Issuing a savepoint would just mask failures.

What would be actually useful is to be able to tab-complete even in
the midst of a failed transaction block ... but savepoints as such
won't get us there, and I have no good ideas about what would.

			regards, tom lane