Re: Tab completion for CREATE TYPE
От | Thomas Munro |
---|---|
Тема | Re: Tab completion for CREATE TYPE |
Дата | |
Msg-id | CA+hUKGJz-pdMgWXroiwvN-aeG4-AjdWj3gWdQKOSa8g65spdVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tab completion for CREATE TYPE (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: