Thread: feature request
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.
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
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
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
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
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
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
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...
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
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.
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