IF (NOT) EXISTS in psql-completion

On 05.02.2016 11:09, Kyotaro HORIGUCHI wrote:

Hello,

I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion. However, the current delimit-matching
mechanism is not so capable (or is complexty-prone) to live with
such noises. I have proposed to use regular expressions or
simplified one for the robustness but it was too complex to be
applied.

This is another answer for the problem. Removal of such words
on-the-fly makes further matching more robust.

Next, currently some CREATE xxx subsyntaxes of CREATE SCHEMA are
matched using TailMatching but it makes difficult the
options-removal operations, which needs forward matching.

So I introduced two things to resolve them by this patch.

I did some tests with your patch. But I am not confident in tab-complete.c.

And I have some notes:

1 - I execute git apply command and get the following warning:

../0001-Suggest-IF-NOT-EXISTS-for-tab-completion-of-psql.patch:302:
trailing whitespace.
/*
warning: 1 line adds whitespace errors.

This is because of superfluous whitespace I think.

2 - In psql I write "create table if" and press <TAB>. psql adds the
following:

create table IF NOT EXISTS

I think psql should continue with lower case if user wrote query with
loser case text:

create table if not exists

3 - Same with "IF EXISTS". If a write "alter view if" and press <TAB>
psql writes:

alter view IF EXISTS

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello, thank you for the comments.

At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakirov <a.zakirov@postgrespro.ru> wrote in <56C1C80D.7020101@postgrespro.ru>

On 05.02.2016 11:09, Kyotaro HORIGUCHI wrote:

Hello,

I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion. However, the current delimit-matching
mechanism is not so capable (or is complexty-prone) to live with
such noises. I have proposed to use regular expressions or
simplified one for the robustness but it was too complex to be
applied.

This is another answer for the problem. Removal of such words
on-the-fly makes further matching more robust.

Next, currently some CREATE xxx subsyntaxes of CREATE SCHEMA are
matched using TailMatching but it makes difficult the
options-removal operations, which needs forward matching.

So I introduced two things to resolve them by this patch.

I did some tests with your patch. But I am not confident in
tab-complete.c.

And I have some notes:

1 - I execute git apply command and get the following warning:

../0001-Suggest-IF-NOT-EXISTS-for-tab-completion-of-psql.patch:302:
trailing whitespace.
/*
warning: 1 line adds whitespace errors.

This is because of superfluous whitespace I think.

Oops. I'll remove it.

2 - In psql I write "create table if" and press <TAB>. psql adds the
following:

create table IF NOT EXISTS

I think psql should continue with lower case if user wrote query with
loser case text:

Good catch! Hmm. COMPLETE_WITH_SCHEMA_QUERY() does it. For
example, the following existing completion behaves in the same
way.

"drop index c" =<tab>=> "drop index CONCURRENTLY"

The results of schema queries should be treated in case-sensitive
way so the additional keywords by 'UNION' are also treated
case-sensitively.

COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_indexes,
" UNION SELECT 'CONCURRENTLY'");

Fixing this is another problem. So I'd like to leave this alone
here.

create table if not exists

3 - Same with "IF EXISTS". If a write "alter view if" and press <TAB>
psql writes:

alter view IF EXISTS

regards,

--
堀口恭太郎

日本電信電話株式会社 NTTオープンソースソフトウェアセンタ
Phone: 03-5860-5115 / Fax: 03-5463-5490

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello, this is the new version of this patch.

At Fri, 26 Feb 2016 13:17:26 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20160226.131726.54224488.horiguchi.kyotaro@lab.ntt.co.jp>

Hello, thank you for the comments.

At Mon, 15 Feb 2016 15:43:57 +0300, Artur Zakirov <a.zakirov@postgrespro.ru> wrote in <56C1C80D.7020101@postgrespro.ru>

I did some tests with your patch. But I am not confident in
tab-complete.c.

And I have some notes:

1 - I execute git apply command and get the following warning:

../0001-Suggest-IF-NOT-EXISTS-for-tab-completion-of-psql.patch:302:
trailing whitespace.
/*
warning: 1 line adds whitespace errors.

This is because of superfluous whitespace I think.

Oops. I'll remove it.

2 - In psql I write "create table if" and press <TAB>. psql adds the
following:

create table IF NOT EXISTS

I think psql should continue with lower case if user wrote query with
loser case text:

Good catch! Hmm. COMPLETE_WITH_SCHEMA_QUERY() does it. For
example, the following existing completion behaves in the same
way.

"drop index c" =<tab>=> "drop index CONCURRENTLY"

The results of schema queries should be treated in case-sensitive
way so the additional keywords by 'UNION' are also treated
case-sensitively.

COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_indexes,
" UNION SELECT 'CONCURRENTLY'");

Fixing this is another problem. So I'd like to leave this alone
here.

create table if not exists

3 - Same with "IF EXISTS". If a write "alter view if" and press <TAB>
psql writes:

alter view IF EXISTS

Finally, the only thing done in this new patch is removing one
dangling space.

reagrds,

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Fri, Feb 26, 2016 at 2:37 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:

Hello, this is the new version of this patch.

The CommitFest entry for this patch is messed up. It shows no author,
even though I'm pretty sure that a patch has to have one by
definition.

https://commitfest.postgresql.org/9/518/

Also, this patch was listed as Waiting on Author, but it's been
updated since it was last reviewed, so I switched it back to Needs
Review. Can someone please review it and, if appropriate, mark it
Ready for Committer?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/15/16 1:42 PM, Robert Haas wrote:

On Fri, Feb 26, 2016 at 2:37 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:

Hello, this is the new version of this patch.

The CommitFest entry for this patch is messed up. It shows no author,
even though I'm pretty sure that a patch has to have one by
definition.

https://commitfest.postgresql.org/9/518/

Also, this patch was listed as Waiting on Author, but it's been
updated since it was last reviewed, so I switched it back to Needs
Review. Can someone please review it and, if appropriate, mark it
Ready for Committer?

Author has been set to Kyotaro Horiguchi.

--
-David
david@pgmasters.net

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:

I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion.

To repeat the question I raised in the previous commit fest about tab
completion: Why do you want tab completion for IF NOT EXISTS? When you
tab complete, the completion mechanism will show you whether the item in
question exists. What is the use case?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hello,

# It seems that I have been forgotten in the recepient list..

At Tue, 15 Mar 2016 22:09:59 -0400, Peter Eisentraut <peter_e@gmx.net> wrote in <56E8C077.2000903@gmx.net>

On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:

I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion.

To repeat the question I raised in the previous commit fest about tab
completion: Why do you want tab completion for IF NOT EXISTS? When you
tab complete, the completion mechanism will show you whether the item in
question exists. What is the use case?

Ah, I think I understand you question. It's not about IF EXISTS,
but only IF NOT EXSTS. It is needed when repeated execution of
the same SQL statement will be done using command line
history. Such stocks of commands in history is often
convenient. And sometimes I rely on psql-completion to write a
SQL script. The completions for such words seemingly useless on
instant-execution will be handy to do that.

Another thing I want to do by this patch is that we can get
completion even after such optional words. I have been annoyed
many times by this. Some of them, such as UNIQUE, TEMPORARY and
CONCURRENTLY are treated but they just doubles the matching
condition expressions.

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

Mmm. Have I broken the entry?

At Tue, 15 Mar 2016 13:55:24 -0400, David Steele <david@pgmasters.net> wrote in <56E84C8C.7060902@pgmasters.net>

On 3/15/16 1:42 PM, Robert Haas wrote:

On Fri, Feb 26, 2016 at 2:37 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:

Hello, this is the new version of this patch.

The CommitFest entry for this patch is messed up. It shows no author,
even though I'm pretty sure that a patch has to have one by
definition.

https://commitfest.postgresql.org/9/518/

Also, this patch was listed as Waiting on Author, but it's been
updated since it was last reviewed, so I switched it back to Needs
Review. Can someone please review it and, if appropriate, mark it
Ready for Committer?

Author has been set to Kyotaro Horiguchi.

Thank you for repairing it.

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

On Wed, Mar 16, 2016 at 2:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Fri, Feb 26, 2016 at 2:37 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:

Hello, this is the new version of this patch.

The CommitFest entry for this patch is messed up. It shows no author,
even though I'm pretty sure that a patch has to have one by
definition.

The CF app does not require an author name when the entry is first
created. The author needs to be added afterwards. A message-id, a
description and a category are the mandatory things.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Hi

2016-03-16 5:01 GMT+01:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp

:

Hello,

# It seems that I have been forgotten in the recepient list..

At Tue, 15 Mar 2016 22:09:59 -0400, Peter Eisentraut <peter_e@gmx.net>
wrote in <56E8C077.2000903@gmx.net>

On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:

I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion.

To repeat the question I raised in the previous commit fest about tab
completion: Why do you want tab completion for IF NOT EXISTS? When you
tab complete, the completion mechanism will show you whether the item in
question exists. What is the use case?

Ah, I think I understand you question. It's not about IF EXISTS,
but only IF NOT EXSTS. It is needed when repeated execution of
the same SQL statement will be done using command line
history. Such stocks of commands in history is often
convenient. And sometimes I rely on psql-completion to write a
SQL script. The completions for such words seemingly useless on
instant-execution will be handy to do that.

Another thing I want to do by this patch is that we can get
completion even after such optional words. I have been annoyed
many times by this. Some of them, such as UNIQUE, TEMPORARY and
CONCURRENTLY are treated but they just doubles the matching
condition expressions.

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.

Regards

Pavel

Hi

2016-03-17 21:02 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:

Hi

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.

I checked it against sql help and these statements doesn't work

alter foreign table hhhh drop column
alter text search configuration jjj drop mapping
alter type hhh drop attribute
drop cast
drop extension
drop operator
drop text search
drop transform -- missing autocomplete completely
drop user mapping
alter table jjj add column
create temp sequence
create sequence

Regards

Pavel

Hi Kyotaro,

On 3/18/16 3:22 AM, 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.

I checked it against sql help and these statements doesn't work

alter foreign table hhhh drop column
alter text search configuration jjj drop mapping
alter type hhh drop attribute
drop cast
drop extension
drop operator
drop text search
drop transform -- missing autocomplete completely
drop user mapping
alter table jjj add column
create temp sequence
create sequence

Do you have an idea of when you will have a new patch ready?

Thanks,
--
-David
david@pgmasters.net

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Thank you Pavel, David.

Thank you for pointing syntaxes to be addressed. Most of the are
addressed in the attached patch.

At Tue, 22 Mar 2016 12:57:27 -0400, David Steele <david@pgmasters.net> wrote in <56F17977.8040503@pgmasters.net>

Hi Kyotaro,

On 3/18/16 3:22 AM, 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.

I checked it against sql help and these statements doesn't work

Thank you very much.

alter foreign table hhhh drop column
drop cast
drop operator
drop transform -- missing autocomplete completely

These are not done. Each of them has issues to be addressed
before adding completion of IF EXISTS.

alter text search configuration jjj drop mapping
alter type hhh drop attribute
drop extension

Done.

drop text search

I don't see the syntax "drop text search [if exists]". drop text
search (configuration|dictionary|parser|template) are already
addressed.

drop user mapping

"drop user" was not completed with "mapping". I added it then
addressed this. (This might be another issue.)

alter table jjj add column

Done if it is mentioning DROP COLUMN. But new two macros
HeadMatches6 and 7 are introduced together.

create temp sequence
create sequence

DROP SEQUENCE is already completed with IF EXISTS. CREATE [TEMP]
SEQUENCE with IF NOT EXISTS is added.

Do you have an idea of when you will have a new patch ready?

Sorry to to have been late. The attached is the revised version.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Hi

2016-03-29 8:43 GMT+02:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp

:

Thank you Pavel, David.

Thank you for pointing syntaxes to be addressed. Most of the are
addressed in the attached patch.

At Tue, 22 Mar 2016 12:57:27 -0400, David Steele <david@pgmasters.net>
wrote in <56F17977.8040503@pgmasters.net>

Hi Kyotaro,

On 3/18/16 3:22 AM, 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.

I checked it against sql help and these statements doesn't work

Thank you very much.

alter foreign table hhhh drop column
drop cast
drop operator
drop transform -- missing autocomplete completely

These are not done. Each of them has issues to be addressed
before adding completion of IF EXISTS.

alter text search configuration jjj drop mapping
alter type hhh drop attribute
drop extension

Done.

drop text search

I don't see the syntax "drop text search [if exists]". drop text
search (configuration|dictionary|parser|template) are already
addressed.

ok, probably my mistake. I am sorry.

drop user mapping

"drop user" was not completed with "mapping". I added it then
addressed this. (This might be another issue.)

alter table jjj add column

Done if it is mentioning DROP COLUMN. But new two macros
HeadMatches6 and 7 are introduced together.

create temp sequence
create sequence

DROP SEQUENCE is already completed with IF EXISTS. CREATE [TEMP]
SEQUENCE with IF NOT EXISTS is added.

Do you have an idea of when you will have a new patch ready?

Sorry to to have been late. The attached is the revised version.

I'll check it today.

Regards

Pavel

On 29.03.2016 10:59, Pavel Stehule wrote:

Hi

2016-03-29 8:43 GMT+02:00 Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp <mailto:horiguchi.kyotaro@lab.ntt.co.jp>>:

Thank you Pavel, David.

Thank you for pointing syntaxes to be addressed. Most of the are
addressed in the attached patch.

At Tue, 22 Mar 2016 12:57:27 -0400, David Steele
<david@pgmasters.net <mailto:david@pgmasters.net>> wrote in
<56F17977.8040503@pgmasters.net <mailto:56F17977.8040503@pgmasters.net>>

Hi Kyotaro,

On 3/18/16 3:22 AM, 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".

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

Hi, Pavel.

At Tue, 29 Mar 2016 09:59:01 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRDEPgGyMz2aXgTL33PuD7X+xieaO++wa+V9nQPQiYDMGQ@mail.gmail.com>

On 3/18/16 3:22 AM, 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.

I understand that and feel the same. But I don't want to put
puzzling code. Defining a macro enable this by writing as the
following.

else if (Matches2("ALTER", "TABLE"))
COMPLETE_WITH_SCHEMA_QUERY(
Query_for_list_of_tables,
ADDLIST("",
"('IF EXISTS'), ('ALL IN TABLESPACE')",
"('if exists'), ('all in tablespace')"));

...

else if (Matches2("ALTER", "POLICY"))
COMPLETE_WITH_QUERY(
ADDLIST(Query_for_list_of_policies,
"('IF EXISTS')", "('if exists')"));

This will work as you expects but it looks quite redundant, but
avoiding dynamic string (and/or malloc) operation would lead to
the similar results. Integrating the ADDLIST into
COMPLETE... might make the situation better.

The attached patch does it only for "ALTER TABLE" and "ALTER
POLICY".

I checked it against sql help and these statements doesn't work

Thank you very much.

alter foreign table hhhh drop column
drop cast
drop operator
drop transform -- missing autocomplete completely

These are not done. Each of them has issues to be addressed
before adding completion of IF EXISTS.

alter text search configuration jjj drop mapping
alter type hhh drop attribute
drop extension

Done.

drop text search

I don't see the syntax "drop text search [if exists]". drop text
search (configuration|dictionary|parser|template) are already
addressed.

ok, probably my mistake. I am sorry.

drop user mapping

"drop user" was not completed with "mapping". I added it then
addressed this. (This might be another issue.)

alter table jjj add column

Done if it is mentioning DROP COLUMN. But new two macros
HeadMatches6 and 7 are introduced together.

create temp sequence
create sequence

DROP SEQUENCE is already completed with IF EXISTS. CREATE [TEMP]
SEQUENCE with IF NOT EXISTS is added.

Do you have an idea of when you will have a new patch ready?

Sorry to to have been late. The attached is the revised version.

I'll check it today.

Thanks.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

Hi, thank you for the suggestion.

At Tue, 29 Mar 2016 12:54:01 +0300, Artur Zakirov <a.zakirov@postgrespro.ru> wrote in <56FA50B9.7000107@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

2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyotaro@lab.ntt.co.jp>:

Hi, Pavel.

At Tue, 29 Mar 2016 09:59:01 +0200, Pavel Stehule <pavel.stehule@gmail.com>
wrote in <
CAFj8pRDEPgGyMz2aXgTL33PuD7X+xieaO++wa+V9nQPQiYDMGQ@mail.gmail.com>

On 3/18/16 3:22 AM, 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.

I understand that and feel the same. But I don't want to put
puzzling code. Defining a macro enable this by writing as the
following.

puzzle is wrong, but nonconsistent behave is not acceptable

Regards

Pavel

Hello,

At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule <pavel.stehule@gmail.com> wrote in <CAFj8pRCnrpdSqSozg4Y8__2LFyiNqUCE=KPzFw1+AF_LutmRiQ@mail.gmail.com>

2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI <

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.

I understand that and feel the same. But I don't want to put
puzzling code. Defining a macro enable this by writing as the
following.

puzzle is wrong, but nonconsistent behave is not acceptable

Mmm. Ok, The attched patch, which applies on top of the
IF(NOT)EXIST patch, does this in rather saner appearance, but
needs to run additional C function at runtime and additional some
macros. The function is called up to once per completion, so it
won't be a performance problem.

else if (Matches2("ALTER", "TABLE"))
COMPLETE_WITH_SCHEMA_QUERY(Query_for_list_of_tables,
ADDLIST2("", "IF EXISTS", "ALL IN TABLESPACE"));

or

else if (Matches5("ALTER", "TABLE", MatchAny, "DROP", "CONSTRAINT"))
{
completion_info_charp = prev3_wd;
COMPLETE_WITH_QUERY(
ADDLIST1(Query_for_constraint_of_table, "IF EXISTS"));
}

I think this syntax is acceptable. Only keywords follows the
setting of COMP_KEYWORD_CASE, as Artur suggested.

=# alter table <tab>
ALL IN TABLESPACE pg_catalog. public.
alpha. pg_temp_1. x
IF EXISTS pg_toast.
information_schema. pg_toast_temp_1.
=# alter table i<tab>
if exists
information_schema.sql_features
...
=# alter table if<tab>
=# alter table if exists
======
=# alter table I<tab>
=# alter table IF EXISTS // "information_schema" doesn't match.

Since this is another problem from IF (NOT) EXISTS, this is
in separate form.

What do you think about this?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center