Horton

Thread

Commits

  1. Fix tab completion for UPDATE.

  2. Tab completion for CREATE TYPE.

  1. Tab completion for CREATE TYPE

    Thomas Munro <thomas.munro@gmail.com> — 2019-05-14T05:50:58Z

    Hi,

Since I keep forgetting the syntax and options, here is $SUBJECT.

-- 
Thomas Munro
https://enterprisedb.com

  2. Re: Tab completion for CREATE TYPE

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2019-05-14T06:18:07Z

    Hello.

At Tue, 14 May 2019 17:50:58 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in <CA+hUKGLk=0yLDjfviONJLzcHEzygj=x6VbGH43LnXbBUvQb52g@mail.gmail.com>
> Hi,
> 
> Since I keep forgetting the syntax and options, here is $SUBJECT.

I played with this a bit and found that "... (attr=[tab]" (no
space between "r" and "=") complets with '='. Isn't it annoying?

Only "UPDATE hoge SET a=[tab]" behaves the same way among
existing completions.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  3. Re: Tab completion for CREATE TYPE

    Thomas Munro <thomas.munro@gmail.com> — 2019-05-14T06:58:14Z

    On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> I played with this a bit and found that "... (attr=[tab]" (no
> space between "r" and "=") complets with '='. Isn't it annoying?
>
> Only "UPDATE hoge SET a=[tab]" behaves the same way among
> existing completions.

Hmm.  True.  Here's one way to fix that.

-- 
Thomas Munro
https://enterprisedb.com

  4. Re: Tab completion for CREATE TYPE

    Edgy Hacker <edgy.hacker@gmail.com> — 2019-05-14T08:31:17Z

    On Tue, May 14, 2019 at 06:58:14PM +1200, Thomas Munro wrote:
> On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > I played with this a bit and found that "... (attr=[tab]" (no
> > space between "r" and "=") complets with '='. Isn't it annoying?
> >
> > Only "UPDATE hoge SET a=[tab]" behaves the same way among
> > existing completions.
> 
> Hmm.  True.  Here's one way to fix that.

Hmm... just got here.

What happens around here?

> 
> -- 
> Thomas Munro
> https://enterprisedb.com

  5. Re: Tab completion for CREATE TYPE

    Thomas Munro <thomas.munro@gmail.com> — 2019-05-14T09:01:27Z

    On Tue, May 14, 2019 at 8:32 PM Edgy Hacker <edgy.hacker@gmail.com> wrote:
> Hmm... just got here.

Welcome.

> What happens around here?

Please see https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F .

-- 
Thomas Munro
https://enterprisedb.com

  6. Re: Tab completion for CREATE TYPE

    Edgy Hacker <edgy.hacker@gmail.com> — 2019-05-14T09:25:21Z

    On Tue, May 14, 2019 at 09:01:27PM +1200, Thomas Munro wrote:
> On Tue, May 14, 2019 at 8:32 PM Edgy Hacker <edgy.hacker@gmail.com> wrote:
> > Hmm... just got here.
> 
> Welcome.

Thanks.

> 
> > What happens around here?
> 
> Please see https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F .

Not exactly a prospective developer but if it ever comes it...

> 
> -- 
> Thomas Munro
> https://enterprisedb.com

  7. Re: Tab completion for CREATE TYPE

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2019-05-14T11:13:24Z

    At Tue, 14 May 2019 18:58:14 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in <CA+hUKG+ojKTKw=aG6QU=VmPMc8Sq7nM4Ah7fk1e+g1YngCVNmg@mail.gmail.com>
> On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > I played with this a bit and found that "... (attr=[tab]" (no
> > space between "r" and "=") complets with '='. Isn't it annoying?
> >
> > Only "UPDATE hoge SET a=[tab]" behaves the same way among
> > existing completions.
> 
> Hmm.  True.  Here's one way to fix that.

Thanks. That's what was in my mind.

Some definition item names are induced from some current states
(e.g. "CREATE TYPE name AS RANGE (" => "SUBTYPE = ") but I think
it's too much.

COLLATE is not suggested with possible collations but I think
suggesting it is not so useful.

PASSEDBYVALUE is suggested with '=', which is different from
documented syntax but I don't think that's not such a problem for
those who spell this command out.

# By the way, collatable and preferred are boolean which behaves
# the same way with passedbyvalue. Is there any intention in the
# difference in the documentation?

The completion lists contain all possible words correctly (I
think "analyse" is an implicit synonym.).

As the result, I find it perfect.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  8. Re: Tab completion for CREATE TYPE

    Thomas Munro <thomas.munro@gmail.com> — 2019-07-13T04:54:06Z

    On Tue, May 14, 2019 at 11:13 PM Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> At Tue, 14 May 2019 18:58:14 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in <CA+hUKG+ojKTKw=aG6QU=VmPMc8Sq7nM4Ah7fk1e+g1YngCVNmg@mail.gmail.com>
> > On Tue, May 14, 2019 at 6:18 PM Kyotaro HORIGUCHI
> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > > I played with this a bit and found that "... (attr=[tab]" (no
> > > space between "r" and "=") complets with '='. Isn't it annoying?
> > >
> > > Only "UPDATE hoge SET a=[tab]" behaves the same way among
> > > existing completions.
> >
> > Hmm.  True.  Here's one way to fix that.
>
> Thanks. That's what was in my mind.

I pushed a fix for that separately.  I remembered that we had decided
to use MatchAnyExcept("...") instead of "!...", so I did it that way.

> Some definition item names are induced from some current states
> (e.g. "CREATE TYPE name AS RANGE (" => "SUBTYPE = ") but I think
> it's too much.
>
> COLLATE is not suggested with possible collations but I think
> suggesting it is not so useful.

Yes, there is room to make it smarter.

> PASSEDBYVALUE is suggested with '=', which is different from
> documented syntax but I don't think that's not such a problem for
> those who spell this command out.
>
> # By the way, collatable and preferred are boolean which behaves
> # the same way with passedbyvalue. Is there any intention in the
> # difference in the documentation?

Good question.

> The completion lists contain all possible words correctly (I
> think "analyse" is an implicit synonym.).

I am not a fan of doing anything at all to support alternative
spellings for keywords etc, even though I personally use British
spelling in most contexts outside PostgreSQL source code.  We don't
support MATERIALISED, CATALOGUE, BACKWARDS/FORWARDS (with an S), etc,
so I don't know why we have this one single word ANALYSE from a
different spelling system than the one used by SQL.

> As the result, I find it perfect.

Pushed.  Thanks for the review!

-- 
Thomas Munro
https://enterprisedb.com