Re: Remove "FROM" in "DELETE FROM" when using tab-completion

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remove "FROM" in "DELETE FROM" when using tab-completion
Date: 2021-05-10 07:14:56
Message-ID: 20210510071456.gyvvogetxkcf5m4c@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 10, 2021 at 06:36:19AM +0000, tanghy(dot)fnst(at)fujitsu(dot)com wrote:
> On Monday, May 10, 2021 2:48 PM, Julien Rouhaud <rjuju123(at)gmail(dot)com> worte
> >I think the behavior now is correct. The goal of autocompletion is to save
> >keystrokes and time. As the only valid keyword after a DELETE (at least in a
> >DeleteStmt) is FROM, it's a good thing that you get back "DELETE FROM" directly
> >rather than asking that to autocomplete in multiple steps.
> >
> >Now, the \help command is for commands, which is a different thing as the
> >command in that case is DELETE not DELETE FROM, even if you will have to follow
> >your DELETE with a FROM.
>
> Thanks for your reply. I totally agree with you on the convenience of "DELETE FROM" autocompletion.
> But I also noticed some autocompletion for "DELETE" in some cases is just "DELETE" already.
>
> =# EXPLAIN[TAB]
> ANALYZE DECLARE DELETE INSERT SELECT UPDATE VERBOSE
>
> =# COPY ([TAB]
> DELETE INSERT SELECT TABLE UPDATE VALUES WITH
>
> Maybe we should keep the behavior consistent?

Definitely.

> I mean we can change all "DELETE" to "DELETE FROM" or just remove "FROM" for consistency.

We should change all to DELETE FROM (apart from \help of course), and same for
INSERT, change to INSERT INTO everywhere it makes sense.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-05-10 07:27:29 Re: seawasp failing, maybe in glibc allocator
Previous Message Peter Smith 2021-05-10 07:06:11 GetSubscriptionRelations declares too many scan keys