pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Tom Lane <tgl@sss.pgh.pa.us>
To: David G. Johnston <david.g.johnston@gmail.com>
Cc: 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: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PATCH: psql tab completion for SELECT
Date: Mon, 05 Mar 2018 10:04:30 -0500
Message-ID: <12114.1520262270@sss.pgh.pa.us> (raw )
In-Reply-To: <CAKFQuwafBrOnyOZgB1eJvTfRBjZQcwrXjNdL1vyxsiuB5CvM-A@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 >
<10992.1520260903@sss.pgh.pa.us >
<CAKFQuwafBrOnyOZgB1eJvTfRBjZQcwrXjNdL1vyxsiuB5CvM-A@mail.gmail.com >
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Mar 5, 2018 at 7:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> Why not have psql open two sessions to the backend, one with
> application_name 'psql_user' and one with application name "psql_meta" (or
> some such) and have all these queries executed on the psql_meta connection?
If we did it like that, tab completion would fail to see the session's
temp tables, or objects created in the current open transaction.
People might bitch about using twice as many connections, too, although
likely you could finesse that by only opening the second connection if
tab completion actually happens (so that only interactive sessions have
one). Still, the local-objects problem seems like a fatal objection.
regards, tom lane
view thread (47+ messages) latest in thread
Message-ID: <12114.1520262270@sss.pgh.pa.us>
Permalink: ../12114.1520262270@sss.pgh.pa.us/
Also on: postgresql.org/message-id/12114.1520262270@sss.pgh.pa.us
copy link · copy postgr.es
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, david.g.johnston@gmail.com, 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: <12114.1520262270@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