Re: psql tab completion for updatable foreign tables

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql tab completion for updatable foreign tables
Date: 2013-10-18 05:34:38
Message-ID: CAEZATCX2n+SDX_h9Bo3CrP+CpxYdTEdgLfoTkK=DnVPJOyoz0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 October 2013 03:29, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Mon, 2013-07-08 at 16:04 +0000, Dean Rasheed wrote:
>> There was concern that pg_relation_is_updatable() would end up opening
>> every relation in the database, hammering performance. I now realise
>> that these tab-complete queries have a limit (1000 by default) so I
>> don't think this is such an issue. I tested it by creating 10,000
>> randomly named auto-updatable views on top of a table, and didn't see
>> any performance problems.
>
> Even if performance isn't a problem, do we really want tab completion
> interfering with table locking? That might be a step too far.
>

That's a good point. Currently it's calling pg_table_is_visible(),
which is doing similar work opening each relation, but it isn't
locking any of them.

> Personally, I think this is too fancy anyway. I'd just complete all
> views and foreign tables and be done with it. We don't inspect
> permissions either, for example. This might be too confusing for users.
>

Yeah, I think you're probably right.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2013-10-18 06:19:24 Re: Multiple psql -c / -f options
Previous Message Amit Kapila 2013-10-18 05:01:03 Re: ERROR : 'tuple concurrently updated'