Re: PATCH: psql tab completion for SELECT

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Edmund Horner <ejrh00(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PATCH: psql tab completion for SELECT
Date: 2018-04-06 01:29:06
Message-ID: bced97f2-a68a-e5ca-a214-6b99f9d89a6d@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/21/18 02:51, Edmund Horner wrote:
> I still think the number of completions on an empty string is a bit
> too big, but I don't know what to omit. There are around 1700
> completions on the empty "postgres" database in my testing, and we
> show the first 1000 (arbitrarily limited, as the generated SQL has
> LIMIT 1000 but no ORDER BY).
>
> Should we just leave it as is?
>
> Whether we improve the filtering or not, I'm optimistic the feature
> will be committed in this CF or the next.

I looked at this a bit now. I think it still needs some work.

Some of the queries for older versions contain syntax errors that causes
them not to work.

For example, in 80100:

"'internal'::regtype != ALL ([.proargtypes) "

The query definition structures are missing a comma between selcondition
and viscondition. This causes all the following fields to be
misassigned. I'm not quite sure how it actually works at all some of
the time. There might be another bug that offsets this one.

I'd like to see a short comment what is different between each of the
version queries. You had a list earlier in the thread.

The selection of which functions to show can be further refined.

I don't think the contents of pg_amproc and pg_cast should be excluded.
Some of those functions are useful. Similarly for pg_operator.oprcode.

Things like oprrest and oprjoin will already be excluded because they
have "internal" arguments. Similarly for some columns in pg_aggregate.

There are also additional pseudo-types that should be excluded. See
pg_type.typtype = 'p', except some of those should not be excluded.
Needs more thought.

Considering these issues, I think it would be appropriate to move this
patch to the next commitfest.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-04-06 01:33:17 Re: [HACKERS] path toward faster partition pruning
Previous Message Craig Ringer 2018-04-06 01:27:05 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS