On 5 March 2018 at 08:06, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I looked into this patch and was disappointed to discover that it had
> only a very ad-hoc solution to the problem of version-dependent tab
> completion queries. We need something better --- in particular, the
> recent prokind changes mean that there needs to be a way to make
> SchemaQuery queries version-dependent.
Thanks for the review Tom.
I was avoiding changing things that already worked and hence ended up
with the ad-hoc code. It's much better have a unified approach to
handling this, though.
> So ... here is a modest proposal. It invents a VersionedQuery concept
> and also extends the SchemaQuery infrastructure to allow those to be
> versioned. I have not taken this nearly as far as it could be taken,
> since it's mostly just proposing mechanism. To illustrate the
> VersionedQuery infrastructure, I fixed it so it wouldn't send
> publication/subscription queries to pre-v10 servers, and to illustrate
> the versioned SchemaQuery infrastructure, I fixed the prokind problems.
(Hmm, I guess the new prokind column may be germane to my query for
callable functions.)
> 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.
The SELECT completion patch was definitely ugly. I think the
VersionedQuery is a nice way of making it less ad-hoc, but the work of
writing the numerous query versions, where necessary, remains.
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}
};
I do think the version indicators are nicer when they mean "supported
as of this server version" rather than my "fallback if the server
version is prior to this".
Is it overkill to have so many variations?
I am still just slightly unclear on where we are in relation to the
SAVEPOINT patch -- is that redundant now?
For SELECT support, I would be happy with applying:
a. Your patch
b. A reworked simple SELECT patch (possibly with fewer query versions)
c. A SAVEPOINT patch *if* it's deemed useful [1]
And perhaps later,
d. A cleverer SELECT patch (supporting additional items after the
first comma, for instance)
> As a separate line of work, the infrastructure could be applied to fix
> the pre-existing places where tab completion fails against old servers.
> But that's probably work for v12 or beyond, unless somebody's really
> motivated to do it right now.
>
> regards, tom lane
Edmund
[1] There is more complexity with tab completions and transactions
than I want to tackle just for SELECT; see
https://www.postgresql.org/message-id/flat/CAMyN-kAyFTC4Xavp%2BD6XYOoAOZQW2%3Dc79htji06DXF%2BuF6StOQ%40mail.gmail.com#CAMyN-kAyFTC4Xavp+D6XYOoAOZQW2=c79htji06dxf+uf6s...@mail.gmail.com
