Re: IF (NOT) EXISTS in psql-completion

Hi, thank you for the suggestion.

At Tue, 29 Mar 2016 12:54:01 +0300, Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> wrote in <56FA50B9(dot)7000107(at)postgrespro(dot)ru>
> On 29.03.2016 10:59, Pavel Stehule wrote:
> > > > I am looking this patch. It looks well, but this feature doesn't
> > > > respect upper or lower chars. It enforce upper chars. This is
> > > > not
> > > > consistent with any other autocomplete.
> >
> > As mentioned before, upper-lower problem is an existing
> > issue. The case of the words in a query result list cannot be
> > edited since it may contain words that should not be changed,
> > such as relation names. So we can address it only before issueing
> > a query but I haven't found simple way to do it.
> >
> >
> > This is unpleasant. I am sorry. I had very uncomfortable feeling from
> > this behave. I am thinking so it should be solvable - you have to
> > convert only keyword IF EXISTS or IF NOT EXISTS. Maybe there are not
> > trivial solution, but this should be fixed.
> >
>
> Hello,
>
> Can we do something like in the patch? This patch should be applied
> after the patch
> "0001-Suggest-IF-NOT-EXISTS-for-tab-completion-of-psql_v3.patch".

Unfortunately, all completions are shown in upper-case with it
for some cases (since COMP_KEYWORD_CASE is upper as the default
on my environment). This prevents names, that are not SQL
keywords, from getting further completion.

> =# alter table <tab>
> ALL IN TABLESPACE PG_CATALOG. PUBLIC.
> ALPHA. PG_TEMP_1. X
> IF EXISTS PG_TOAST.
> INFORMATION_SCHEMA. PG_TOAST_TEMP_1.

pg_strdup_keyword_case follows COMP_KEYWORD_CASE pset variable
which instructs how *SQL keywords* should be handled. It is not
for this usage. And as mentioned before, SQL keywords and
identifiers cannot be treated in the same way, so the place is
not suitable to do this.

By the way, memory blocks that readline sees are freed by it but
blocks allocated by the additional pstrdup seems abandoned
without being freed. Actually, the address of newly allocated
blocks seems increasing time by time slowly *even without this
patch*..

Of course, no one seems to be able to rush into out of memory by
this leak, though..

Anyway, using malloc is one reason of additional complexity and
it is the main cause that I avoided dynamic memory allocation.

Thoughts?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center