From: | Edmund Horner <ejrh00(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PATCH: psql tab completion for SELECT |
Date: | 2018-04-08 01:59:15 |
Message-ID: | CAMyN-kDwCwUOg4ZPmvpaa7nRRm3P-xfMx9K_YZSg1afiE-kuvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6 April 2018 at 13:29, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> 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.
You're right. There were lots of useful functions being excluded by
the pg_amproc, pg_cast, and oprcode checks. And all the oprrest and
oprjoin functions are already excluded, so I can remove that check.
Perhaps we should remove the "appears in this catalog table" exclusion
checks, and just use argument and return type?
> 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.
I don't know much about some of the pseudotypes but this is what I propose:
any*, record, _record, cstring should NOT be excluded
void should NOT be excluded for return type (and perhaps in general;
void_out and void_send are callable, if not hugely useful in psql)
trigger, event_trigger should be excluded
internal, opaque, unknown, pg_ddl_command should be excluded
language_handler, tsm_handler, index_am_handler, fdw_handler should be excluded
For modern servers, our query can be simplified to something like:
SELECT distinct pg_catalog.quote_ident(p.proname)
FROM pg_catalog.pg_proc p
WHERE NOT arrayoverlap(ARRAY['internal', 'event_trigger', 'internal',
'opaque', 'unknown', 'pg_ddl_command', 'language_handler',
'tsm_handler', 'index_am_handler', 'fdw_handler']::regtype[]::oid[],
ARRAY(SELECT p.prorettype UNION SELECT unnest(proargtypes)));
What do you think?
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-04-08 02:16:07 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Previous Message | Andres Freund | 2018-04-08 01:30:05 | Re: Bring atomic flag fallback up to snuff |