pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Edmund Horner <ejrh00@gmail.com>
Cc: Vik Fearing <vik.fearing@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: PATCH: psql tab completion for SELECT
Date: Mon, 05 Mar 2018 09:41:43 -0500
Message-ID: <10992.1520260903@sss.pgh.pa.us> (raw)
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>

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




view thread (47+ messages)  latest in thread

Message-ID: <10992.1520260903@sss.pgh.pa.us>
Permalink:  ../10992.1520260903@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10992.1520260903@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, ejrh00@gmail.com, vik.fearing@2ndquadrant.com, andres@anarazel.de, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: PATCH: psql tab completion for SELECT
  In-Reply-To: <10992.1520260903@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox