Thread: feature request

feature request

From
Tim Uckun
Date:
The drop down boxes in pgadmin don't have autocomplete and don't jump
to the items that start with the character you type.  Most of them
have a very long list of items in seemingly random order (function
return types for example) so an autocomplete would make this a lot
easier to use.

Also while I am at it.  IMHO...


pgadmin should automatically save all the queries you are working on
when you quit. There is really no reason to prompt the user as saving
the queries doesn't take up much space. In fact I would say pgadmin
should keep every query that successfully ran maybe in an internal
database of some sort.

pgadmin should have a tabbed interface for queries instead of having
every query in a different window.

pgadmin should allow me to select a schema so I don't have to set
search path or schema before every query (or specify the schema name
in the query).

where do I define tab size for indents?

If I run multiple queries I should be able to see all the results for
all the queries instead of just the last one. This is especially
important if the last statement is "rollback" or "commit".

ability to save results as CSV or better yet being able to put the
results into the clipboard.


Re: feature request

From
Dave Page
Date:
On Tue, Aug 30, 2011 at 11:56 AM, Tim Uckun <timuckun@gmail.com> wrote:
> The drop down boxes in pgadmin don't have autocomplete and don't jump
> to the items that start with the character you type.  Most of them
> have a very long list of items in seemingly random order (function
> return types for example) so an autocomplete would make this a lot
> easier to use.

They do, if you use Windows or Mac. The controls suck on GTK though,
and don't offer all the events that wxWidgets needs to do the same job
on Linux/Solaris.

> Also while I am at it.  IMHO...
>
>
> pgadmin should automatically save all the queries you are working on
> when you quit. There is really no reason to prompt the user as saving
> the queries doesn't take up much space.

No, because users often don't want to overwrite a query that they have
previously saved (I often use a standard query I have saved and tweak
it for a one-off use for example).

> In fact I would say pgadmin
> should keep every query that successfully ran maybe in an internal
> database of some sort.

It does. Use the combo box above the SQL pane.

> pgadmin should have a tabbed interface for queries instead of having
> every query in a different window.

No, because you would end up with less screen space as we already have
multiple tabsets within the query window, and you wouldn't be able to
use query windows on multiple monitors.

> pgadmin should allow me to select a schema so I don't have to set
> search path or schema before every query (or specify the schema name
> in the query).

Why? That just seems like a waste of screen space to me.

> where do I define tab size for indents?

File -> Preferences/Options -> Query Tool

> If I run multiple queries I should be able to see all the results for
> all the queries instead of just the last one. This is especially
> important if the last statement is "rollback" or "commit".

libpq doesn't support multiple resultsets in a single query unfortunately.

> ability to save results as CSV or better yet being able to put the
> results into the clipboard.

You can do both already. Use File -> Export, or select a block of
cells and copy.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: feature request

From
Guillaume Lelarge
Date:
On Tue, 2011-08-30 at 12:31 +0100, Dave Page wrote:
> On Tue, Aug 30, 2011 at 11:56 AM, Tim Uckun <timuckun@gmail.com> wrote:
> > The drop down boxes in pgadmin don't have autocomplete and don't jump
> > to the items that start with the character you type.  Most of them
> > have a very long list of items in seemingly random order (function
> > return types for example) so an autocomplete would make this a lot
> > easier to use.
> 
> They do, if you use Windows or Mac. The controls suck on GTK though,
> and don't offer all the events that wxWidgets needs to do the same job
> on Linux/Solaris.
> 

+1

Hope it will get better with wxWidgets 3.0 when it will be released.

> [...]
> > If I run multiple queries I should be able to see all the results for
> > all the queries instead of just the last one. This is especially
> > important if the last statement is "rollback" or "commit".
> 
> libpq doesn't support multiple resultsets in a single query unfortunately.
> 

As a matter of fact, it does (see
http://pgolub.wordpress.com/2009/11/17/script-slicing-by-pgmdd/), and I
really want pgAdmin to use this. Still need to find a good UI and some
time to work on it :)


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com



Re: feature request

From
Dave Page
Date:
On Tue, Aug 30, 2011 at 6:15 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
>>
>> libpq doesn't support multiple resultsets in a single query unfortunately.
>>
>
> As a matter of fact, it does (see
> http://pgolub.wordpress.com/2009/11/17/script-slicing-by-pgmdd/), and I
> really want pgAdmin to use this. Still need to find a good UI and some
> time to work on it :)

Err, no it doesn't. The blog you've referenced describes how PgMDD
takes the PostgreSQL 8.3 parser and uses it to pre-parse scripts into
individual statements on the client, which it then executes
individually. That's similar to what's being asked for here, but has
the rather nasty limitation of not understanding PG 8.4+'s grammar.

Libpq itself only supports a single resultset for multi-part
statements. Even in 9.1, the docs say:

The command string can include multiple SQL commands (separated by
semicolons). Multiple queries sent in a single PQexec call are
processed in a single transaction, unless there are explicit
BEGIN/COMMIT commands included in the query string to divide it into
multiple transactions. Note however that the returned PGresult
structure describes only the result of the last command executed from
the string. Should one of the commands fail, processing of the string
stops with it and the returned PGresult describes the error condition.

(http://www.postgresql.org/docs/9.1/static/libpq-exec.html#LIBPQ-EXEC-MAIN)

In other words, only the last resultset is accessible.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: feature request

From
Guillaume Lelarge
Date:
On Tue, 2011-08-30 at 19:29 +0100, Dave Page wrote:
> On Tue, Aug 30, 2011 at 6:15 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> >>
> >> libpq doesn't support multiple resultsets in a single query unfortunately.
> >>
> >
> > As a matter of fact, it does (see
> > http://pgolub.wordpress.com/2009/11/17/script-slicing-by-pgmdd/), and I
> > really want pgAdmin to use this. Still need to find a good UI and some
> > time to work on it :)
> 
> Err, no it doesn't. The blog you've referenced describes how PgMDD
> takes the PostgreSQL 8.3 parser and uses it to pre-parse scripts into
> individual statements on the client, which it then executes
> individually. That's similar to what's being asked for here, but has
> the rather nasty limitation of not understanding PG 8.4+'s grammar.
> 
> Libpq itself only supports a single resultset for multi-part
> statements. Even in 9.1, the docs say:
> 
> The command string can include multiple SQL commands (separated by
> semicolons). Multiple queries sent in a single PQexec call are
> processed in a single transaction, unless there are explicit
> BEGIN/COMMIT commands included in the query string to divide it into
> multiple transactions. Note however that the returned PGresult
> structure describes only the result of the last command executed from
> the string. Should one of the commands fail, processing of the string
> stops with it and the returned PGresult describes the error condition.
> 
> (http://www.postgresql.org/docs/9.1/static/libpq-exec.html#LIBPQ-EXEC-MAIN)
> 
> In other words, only the last resultset is accessible.
> 

You're right for PQexec. And wrong for PQsendQuery, which is the one we
use on the query tool.

And to quote the fine manual :)
(http://www.postgresql.org/docs/9.1/static/libpq-async.html#LIBPQ-PQSENDQUERY):
After successfully calling PQsendQuery, call PQgetResult one or more
times to obtain the results. PQsendQuery cannot be called again (on the
same connection) until PQgetResult has returned a null pointer,
indicating that the command is done. 


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com



Re: feature request

From
Dave Page
Date:
On Tue, Aug 30, 2011 at 8:30 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> On Tue, 2011-08-30 at 19:29 +0100, Dave Page wrote:
>> On Tue, Aug 30, 2011 at 6:15 PM, Guillaume Lelarge
>> <guillaume@lelarge.info> wrote:
>> >>
>> >> libpq doesn't support multiple resultsets in a single query unfortunately.
>> >>
>> >
>> > As a matter of fact, it does (see
>> > http://pgolub.wordpress.com/2009/11/17/script-slicing-by-pgmdd/), and I
>> > really want pgAdmin to use this. Still need to find a good UI and some
>> > time to work on it :)
>>
>> Err, no it doesn't. The blog you've referenced describes how PgMDD
>> takes the PostgreSQL 8.3 parser and uses it to pre-parse scripts into
>> individual statements on the client, which it then executes
>> individually. That's similar to what's being asked for here, but has
>> the rather nasty limitation of not understanding PG 8.4+'s grammar.
>>
>> Libpq itself only supports a single resultset for multi-part
>> statements. Even in 9.1, the docs say:
>>
>> The command string can include multiple SQL commands (separated by
>> semicolons). Multiple queries sent in a single PQexec call are
>> processed in a single transaction, unless there are explicit
>> BEGIN/COMMIT commands included in the query string to divide it into
>> multiple transactions. Note however that the returned PGresult
>> structure describes only the result of the last command executed from
>> the string. Should one of the commands fail, processing of the string
>> stops with it and the returned PGresult describes the error condition.
>>
>> (http://www.postgresql.org/docs/9.1/static/libpq-exec.html#LIBPQ-EXEC-MAIN)
>>
>> In other words, only the last resultset is accessible.
>>
>
> You're right for PQexec. And wrong for PQsendQuery, which is the one we
> use on the query tool.
>
> And to quote the fine manual :)
> (http://www.postgresql.org/docs/9.1/static/libpq-async.html#LIBPQ-PQSENDQUERY):
> After successfully calling PQsendQuery, call PQgetResult one or more
> times to obtain the results. PQsendQuery cannot be called again (on the
> same connection) until PQgetResult has returned a null pointer,
> indicating that the command is done.

Oh, I stand corrected. That's pretty neat - I had read that before I
think I mis-parsed it to mean that you call PQgetResult to get more
results for the one and only resultset.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: feature request

From
Guillaume Lelarge
Date:
On Tue, 2011-08-30 at 20:42 +0100, Dave Page wrote:
> On Tue, Aug 30, 2011 at 8:30 PM, Guillaume Lelarge
> <guillaume@lelarge.info> wrote:
> > On Tue, 2011-08-30 at 19:29 +0100, Dave Page wrote:
> >> On Tue, Aug 30, 2011 at 6:15 PM, Guillaume Lelarge
> >> <guillaume@lelarge.info> wrote:
> >> >>
> >> >> libpq doesn't support multiple resultsets in a single query unfortunately.
> >> >>
> >> >
> >> > As a matter of fact, it does (see
> >> > http://pgolub.wordpress.com/2009/11/17/script-slicing-by-pgmdd/), and I
> >> > really want pgAdmin to use this. Still need to find a good UI and some
> >> > time to work on it :)
> >>
> >> Err, no it doesn't. The blog you've referenced describes how PgMDD
> >> takes the PostgreSQL 8.3 parser and uses it to pre-parse scripts into
> >> individual statements on the client, which it then executes
> >> individually. That's similar to what's being asked for here, but has
> >> the rather nasty limitation of not understanding PG 8.4+'s grammar.
> >>
> >> Libpq itself only supports a single resultset for multi-part
> >> statements. Even in 9.1, the docs say:
> >>
> >> The command string can include multiple SQL commands (separated by
> >> semicolons). Multiple queries sent in a single PQexec call are
> >> processed in a single transaction, unless there are explicit
> >> BEGIN/COMMIT commands included in the query string to divide it into
> >> multiple transactions. Note however that the returned PGresult
> >> structure describes only the result of the last command executed from
> >> the string. Should one of the commands fail, processing of the string
> >> stops with it and the returned PGresult describes the error condition.
> >>
> >> (http://www.postgresql.org/docs/9.1/static/libpq-exec.html#LIBPQ-EXEC-MAIN)
> >>
> >> In other words, only the last resultset is accessible.
> >>
> >
> > You're right for PQexec. And wrong for PQsendQuery, which is the one we
> > use on the query tool.
> >
> > And to quote the fine manual :)
> > (http://www.postgresql.org/docs/9.1/static/libpq-async.html#LIBPQ-PQSENDQUERY):
> > After successfully calling PQsendQuery, call PQgetResult one or more
> > times to obtain the results. PQsendQuery cannot be called again (on the
> > same connection) until PQgetResult has returned a null pointer,
> > indicating that the command is done.
> 
> Oh, I stand corrected. That's pretty neat - I had read that before I
> think I mis-parsed it to mean that you call PQgetResult to get more
> results for the one and only resultset.
> 

Actually, I already tried to do it a few months before. But I didn't go
as far as working on the UI.


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com



Re: feature request

From
Dmitriy MiksIr
Date:

08/30/2011 03:31 PM, Dave Page пишет:
> On Tue, Aug 30, 2011 at 11:56 AM, Tim Uckun<timuckun@gmail.com>  wrote:
>> The drop down boxes in pgadmin don't have autocomplete and don't jump
>> to the items that start with the character you type.  Most of them
>> have a very long list of items in seemingly random order (function
>> return types for example) so an autocomplete would make this a lot
>> easier to use.
>
> They do, if you use Windows or Mac. The controls suck on GTK though,
> and don't offer all the events that wxWidgets needs to do the same job
> on Linux/Solaris.
>


Some combo (for example "Maintanance DB" in New Server dialog) allow to 
type and select. May be switch "Data type" to this type of combo? 
Because it's really annoying to scroll all this datatypes...



Re: feature request

From
Guillaume Lelarge
Date:
On Fri, 2011-09-09 at 23:29 +0400, Dmitriy MiksIr wrote:
> 
> 08/30/2011 03:31 PM, Dave Page пишет:
> > On Tue, Aug 30, 2011 at 11:56 AM, Tim Uckun<timuckun@gmail.com>  wrote:
> >> The drop down boxes in pgadmin don't have autocomplete and don't jump
> >> to the items that start with the character you type.  Most of them
> >> have a very long list of items in seemingly random order (function
> >> return types for example) so an autocomplete would make this a lot
> >> easier to use.
> >
> > They do, if you use Windows or Mac. The controls suck on GTK though,
> > and don't offer all the events that wxWidgets needs to do the same job
> > on Linux/Solaris.
> >
> 
> 
> Some combo (for example "Maintanance DB" in New Server dialog) allow to 
> type and select. May be switch "Data type" to this type of combo? 

This kind of combo has a sense for the maintenance DB. We have no list
of the available databases. So, unless the user choose one of the most
likely ones, they have to type it. That kind of combo is not the good
one for the types combobox.

> Because it's really annoying to scroll all this datatypes...

Completely agree. But I'm still not sure the change you suggest is the
one.


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com



Re: feature request

From
Dmitry MiksIr
Date:
10.09.2011 0:46, Guillaume Lelarge пишет:
>>
>> Some combo (for example "Maintanance DB" in New Server dialog) allow to
>> type and select. May be switch "Data type" to this type of combo?
> This kind of combo has a sense for the maintenance DB. We have no list
> of the available databases. So, unless the user choose one of the most
> likely ones, they have to type it. That kind of combo is not the good
> one for the types combobox.

Why? I have list of the available databases :) Anyway same combo used in 
"Groups" of New Server dialog and some other places.

>
>> Because it's really annoying to scroll all this datatypes...
> Completely agree. But I'm still not sure the change you suggest is the
> one.
>
For me - it's look much better ;) You can type or can select from 
dropdown. Yes, you can make typo, but, i think, it's possible to compare 
with list after type.



Re: feature request

From
Guillaume Lelarge
Date:
On Sat, 2011-09-10 at 06:36 +0400, Dmitry MiksIr wrote:
> 10.09.2011 0:46, Guillaume Lelarge пишет:
> >>
> >> Some combo (for example "Maintanance DB" in New Server dialog) allow to
> >> type and select. May be switch "Data type" to this type of combo?
> > This kind of combo has a sense for the maintenance DB. We have no list
> > of the available databases. So, unless the user choose one of the most
> > likely ones, they have to type it. That kind of combo is not the good
> > one for the types combobox.
> 
> Why? I have list of the available databases :)

Once you're connected to it, yes, it's easy to get the list of the
databases. But when you start creating a server, you're not connected to
it.

>  Anyway same combo used in 
> "Groups" of New Server dialog and some other places.
> 

Once again, it made some sense there too. The only way to add a groupe
is to type the new name in this combo. So, we really have to require
that you can type on this combo, or else you won't be able to add any
groups.

> >> Because it's really annoying to scroll all this datatypes...
> > Completely agree. But I'm still not sure the change you suggest is the
> > one.
> >
> For me - it's look much better ;) You can type or can select from 
> dropdown. Yes, you can make typo, but, i think, it's possible to compare 
> with list after type.
> 

We can still do it till we have a better support for autocompletion on
Linux. We'll need to make that available on Linux only though.


-- 
Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com