Re: PATCH: psql tab completion for SELECT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Edmund Horner <ejrh00(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PATCH: psql tab completion for SELECT
Date: 2018-03-05 15:04:30
Message-ID: 12114.1520262270@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Mar 5, 2018 at 7:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-05 15:08:57 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch, again
Previous Message Tom Lane 2018-03-05 15:00:41 Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)