Hi, thank you for the suggestion. At Tue, 29 Mar 2016 12:54:01 +0300, Artur Zakirov <a.zaki...@postgrespro.ru> wrote in <56fa50b9.7000...@postgrespro.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
