patch: psql variables tabcomplete

On 16 August 2010 10:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:

Hello

I found so there are not support for tabcomple of psql variables.

Regards

Pavel Stehule

s/out of mempry/out of memory/

--
Thom Brown
Registered Linux user: #516935

2010/8/16 Thom Brown <thom@linux.com>:

On 16 August 2010 10:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:

Hello

I found so there are not support for tabcomple of psql variables.

Regards

Pavel Stehule

s/out of mempry/out of memory/

ugh - thank you

Pavel

fixed spelling

Regards

Pavel Stehule

2010/8/16 Pavel Stehule <pavel.stehule@gmail.com>:

On Mon, Aug 16, 2010 at 8:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

fixed spelling

2010/8/16 Pavel Stehule <pavel.stehule@gmail.com>:

I found so there are not support for tabcomple of psql variables.

Contents & Purpose
==================
This small patch adds support for tab-completion of \set meta command in psql.
Variables that can be set with \set include not only user-defined ones but also
many pre-defined ones. So, the patch is useful to remember variable names.

Initial Run
===========
The patch can be applied to git master with one hunk, but it's not a problem.
Hunk #1 succeeded at 2582 (offset 65 lines).

It can be compiled with no warnings, but it might be better to add an explicit
cast for the void * returned from realloc() (if we continue to use it;
see below).

Performance
===========
Since we don't have so many variables at once in normal use, the tab completion
won't be a performance critical part.

Bugs, suggestions, etc.
=======================
BUG: If we have just 100 variables, there is a buffer overrun for the last
NULL sentinel.

realloc() is used in the patch, but it is rarely used in the existing codes.
It is used in converting a single-linked list into an array, but we could
remove it if we use two loops (for length and for copying). Or, we will
still use realloc, a wrapper for pg_realloc() might be better than using
realloc() directly to avoid "out of memory" checks for each callee.

We don't have commands for display a list of such variables and \echo is
not tab-completed even with the patch. "Only supported by \set" might be
a bit unbalanced.

--
Itagaki Takahiro

Hello

2010/10/4 Itagaki Takahiro <itagaki.takahiro@gmail.com>:

On Mon, Aug 16, 2010 at 8:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

fixed spelling

2010/8/16 Pavel Stehule <pavel.stehule@gmail.com>:

I found so there are not support for tabcomple of psql variables.

Contents & Purpose
==================
This small patch adds support for tab-completion of \set meta command in psql.
Variables that can be set with \set include not only user-defined ones but also
many pre-defined ones. So, the patch is useful to remember variable names.

Initial Run
===========
The patch can be applied to git master with one hunk, but it's not a problem.
 Hunk #1 succeeded at 2582 (offset 65 lines).

It can be compiled with no warnings, but it might be better to add an explicit
cast for the void * returned from realloc() (if we continue to use it;
see below).

fixed

Performance
===========
Since we don't have so many variables at once in normal use, the tab completion
won't be a performance critical part.

Bugs, suggestions, etc.
=======================
BUG: If we have just 100 variables, there is a buffer overrun for the last
NULL sentinel.

fixed

realloc() is used in the patch, but it is rarely used in the existing codes.
It is used in converting a single-linked list into an array, but we could
remove it if we use two loops (for length and for copying). Or, we will
still use realloc, a wrapper for pg_realloc() might be better than using
realloc() directly to avoid "out of memory" checks for each callee.

We don't have commands for display a list of such variables and \echo is
not tab-completed even with the patch. "Only supported by \set" might be
a bit unbalanced.

it's good idea. I looked on it - and it is job for other patch. Some
test are in experimental patch. But this needs more work - output is
little bit ugly - I thing so prefix and suffix should not be showed.
So psql autocomplete should to work with some prefixes and suffixes
and this needs a significant changes - so it isn't possible in this
moment - just point for ToDo.

Thank you very much for review.

Regards

Pavel Stehule

Pavel Stehule <pavel.stehule@gmail.com> writes:

2010/10/4 Itagaki Takahiro <itagaki.takahiro@gmail.com>:

We don't have commands for display a list of such variables and \echo is
not tab-completed even with the patch. "Only supported by \set" might be
a bit unbalanced.

it's good idea. I looked on it - and it is job for other patch. Some
test are in experimental patch. But this needs more work - output is
little bit ugly - I thing so prefix and suffix should not be showed.

I went ahead and applied this (with some cleanup). I don't see a very
good reason why the prefix/suffix shouldn't be shown in the completion
data --- after all, that *is* what it's going to type for you. In any
case, preventing that would take some fundamental hacking of the
readline interface; which would be way more work than it's worth,
and probably not very portable across the different versions of
readline either. So I think we should just be happy with this
behavior.

regards, tom lane

2010/10/11 Tom Lane <tgl@sss.pgh.pa.us>:

Pavel Stehule <pavel.stehule@gmail.com> writes:

2010/10/4 Itagaki Takahiro <itagaki.takahiro@gmail.com>:

We don't have commands for display a list of such variables and \echo is
not tab-completed even with the patch. "Only supported by \set" might be
a bit unbalanced.

it's good idea. I looked on it - and it is job for other patch. Some
test are in experimental patch. But this needs more work - output is
little bit ugly - I thing so prefix and suffix should not be showed.

I went ahead and applied this (with some cleanup).  I don't see a very
good reason why the prefix/suffix shouldn't be shown in the completion
data --- after all, that *is* what it's going to type for you.  In any
case, preventing that would take some fundamental hacking of the
readline interface; which would be way more work than it's worth,
and probably not very portable across the different versions of
readline either.  So I think we should just be happy with this
behavior.

I write it before I looked to readline documentation - personally I
don't feel well from output, but the nice output isn't available with
current readline lib :( - so I agree with you. Thank you very much for
commit

Regards

Pavel