Thread: 2 feature requests: data display
I have 2 feature requests on data display: 1. Make the row height sticky: this is handy when looking at multiline values. 2. Always widen the column width for any EXPLAIN [ANALYZE] output to (nearly) window width. Or anyway to more than the narrow default width it has now, which guarantees unreadiblilty. (I use pgadmin 1.10.1 on windows) Thanks, Erik Rijkers
Le 08/03/2010 23:33, Erik Rijkers a écrit : > > I have 2 feature requests on data display: > > 1. Make the row height sticky: this is handy when looking at multiline values. > I don't quite understand what you mean by this? could you explain a bit more? > 2. Always widen the column width for any EXPLAIN [ANALYZE] output to (nearly) window > width. Or anyway to more than the narrow default width it has now, which guarantees > unreadiblilty. > Quite easy to do, AFAICT. -- Guillaume.http://www.postgresqlfr.orghttp://dalibo.com
Le 08/03/2010 23:48, Guillaume Lelarge a écrit : > Le 08/03/2010 23:33, Erik Rijkers a écrit : >> >> I have 2 feature requests on data display: >> >> 1. Make the row height sticky: this is handy when looking at multiline values. >> > > I don't quite understand what you mean by this? could you explain a bit > more? > >> 2. Always widen the column width for any EXPLAIN [ANALYZE] output to (nearly) window >> width. Or anyway to more than the narrow default width it has now, which guarantees >> unreadiblilty. >> > > Quite easy to do, AFAICT. > BTW, I just checked. This is already done when you use the EXPLAIN feature, but not if you execute yourself the EXPLAIN. -- Guillaume.http://www.postgresqlfr.orghttp://dalibo.com
On Mon, March 8, 2010 23:48, Guillaume Lelarge wrote: > Le 08/03/2010 23:33, Erik Rijkers a écrit : >> >> I have 2 feature requests on data display: >> >> 1. Make the row height sticky: this is handy when looking at multiline values. >> > > I don't quite understand what you mean by this? could you explain a bit > more? It is comparable to the 'stickiness' of the data grid's column-widths. If you do (in a 'Query tool' window): select * from ( values ( 'multiline record' || chr(10) || 'that' || chr(10) || 'consists' || chr(10) || 'of more than 1 line' ) ) as t(x) ; followed by F5, if will show the data in a grid with that record's data with the height of a single line. Initially this is OK, but when you enlarge it with the mouse, and press again F5, the enlarged height of the (grid-)row is reset to 1. This should, I think, ideally be 'sticky': it should retain the enlarged height of the grid's row, at least when the query's select-list is the same (or similar?) to the last-ran query (make it comparable to the grid's column width behaviour). >> 2. Always widen the column width for any EXPLAIN [ANALYZE] output to (nearly) window >> width. Or anyway to more than the narrow default width it has now, which guarantees >> unreadiblilty. >> > > Quite easy to do, AFAICT. Great, I hoped that would be the case... Thank you, Erik Rijkers
Hi, I'm seeing behavior that is unexpected. Hopeing to get a better understanding of how PGadmin manages connections I have a query window with 20+sql statements, connected to my fqa database. I'm running sql individually and seeing thatsometimes they are directed to my prod database, instead of the fqa database that is the displayed connection for thewindow. I have several query windows open, but only submitting queries from the active window at this time. I have 2 server status windows open for my fqa and prod database I am switching between the running query, and the system status's to monitor execution. What should I expect pgadmin to do with the multiple connections? Thanks Doug
Le 15/03/2010 15:17, Little, Douglas a écrit : > Hi, > I'm seeing behavior that is unexpected. Hopeing to get a better understanding of how PGadmin manages connections > > I have a query window with 20+sql statements, connected to my fqa database. I'm running sql individually and seeingthat sometimes they are directed to my prod database, instead of the fqa database that is the displayed connectionfor the window. > > I have several query windows open, but only submitting queries from the active window at this time. > I have 2 server status windows open for my fqa and prod database > I am switching between the running query, and the system status's to monitor execution. > > What should I expect pgadmin to do with the multiple connections? > Not sure I completely understand your question, but here is an quick explanation of pgAdmin's use of connections. Behavior depends on the window. The main window (aka the browser window) will have as many connections as necessary. You double-click to connect to a server : you'll have a connection to the maintenance database of this server and a connection to the last database you were connected to (if you choose this option in the Options window and if you were connected to another database than the maintenance one). Then, you have a connection to every database you see without a red cross. You can close a connection with the contextual menu of a database. If you don't, all connection will be closed when you quit the app. The query tool opens a connection to the database you were connected to when you clicked on the query tool button (or chose the query tool item in the menu). If you choose another connection in the combobox of the toolbar, it will open a new connection without closing the first ones. They will all be closed when you will quit the query tool. The status window opens a connection to the maintenance database (usually postgres) of the server you were connected to when you chose the Status window item in the menu. In 1.10, you can select another database for the lock report so that we can show the locked relations' names (which obviously opens another connection to this database). If you change this connection, it closes the other one but keeps the connection to the maintenance database (as it is needed for the other report). When you dump or restore a database, it will launch pg_dump or pg_restore. They will open their own connection to the appropriate database. There are other tools I probably forgot (the configuration ones for example), but they are less important. -- Guillaume.http://www.postgresqlfr.orghttp://dalibo.com