From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Edmund Horner <ejrh00(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: psql tab completion for SELECT |
Date: | 2018-01-18 00:07:18 |
Message-ID: | 2738.1516234038@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Edmund Horner <ejrh00(at)gmail(dot)com> writes:
> On 15 January 2018 at 15:45, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> 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?
Maybe it'd be worth the effort to wrap tab completion queries in
SAVEPOINT/RELEASE SAVEPOINT if we're inside a user transaction
(which we could detect from libpq's state, I believe).
That seems like an independent patch, but it'd be a prerequisite
if you want to issue tab completion queries with version dependencies.
A bigger point here is: do you really want SELECT tab completion
to work only against the latest and greatest server version?
That would become an argument against committing the feature at all;
maybe not enough to tip the scales against it, but still a demerit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-01-18 00:11:20 | Re: Setting BLCKSZ 4kB |
Previous Message | Peter Geoghegan | 2018-01-18 00:00:49 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |