4 ms·

Hello Mike. I would really appreciate it if you can give my new product, pgXplorer (downloadable at pgXplorer.com) a whirl and give some feedback. It is a deskt

Hello Mike. I would really appreciate it if you can give my new product, pgXplorer (downloadable at pgXplorer.com) a whirl and give some feedback. It is a desktop GUI client for postgres v8.4 and above.

mikegreenberg 14y ago
Hi Davy. I really like the minimalist approach to this app. Install was straight forward (but a little sad a Linux version doesn't exist yet). No complicated shortcuts (I like) and basic functions. It seems hard to screw this up. Sadly, I don't use Postgres and I didn't have any databases sitting around to test it against. If you know of a quick way I could test it against a database, I'd be happy to share more. Otherwise, it looks great!
- davyjones 14y ago
  Thanks a ton for the kind words Mike. > but a little sad a Linux version doesn't exist yet Working fervently on this. Couple of issues being sorted out now are: a) undesirable window behaviour and 2) packaging for popular linux flavours. >...I didn't have any databases sitting around to test it against. Unfortunately, the easiest way I can think of is to install postgres on your own machine. As a very very low priority item on your schedule, if you can try out pgXplorer on your local database and give some feedback, I would really appreciate it!
bartonfink 14y ago
Davy - I regularly use psql as part of my job, but I gave pgXplorer a whirl. It seems less responsive than psql, but that's a big reason why I use the command line client anyway. One thing I noticed is that you're asking for "Port" twice in the connection properties dialog - I think you mean "Password" in the second instance. I'm probably not your target audience, but I'd like to know - what's the proposition? Why use pgXplorer instead of pgAdmin, for example?
- davyjones 14y ago
  Thanks a lot for your feedback. I truly appreciate it. Nothing can beat psql in speed in my opinion. pgXplorer carries the overhead of a GUI of course and there is an added level of abstraction when talking to the database. pgXplorer has been built with ease-of-use in mind. > ..you're asking for "Port" twice... Sorry about it. It has been rectified at the source. I shall be updating the installers shortly. > what's the proposition? Why use pgXplorer instead of pgAdmin, for example? Good question. I started with the premise to supplant pgAdmin as the open source GUI tool for postgres. But I don't hold that view anymore. I am thinking of pgXplorer as another open source GUI for postgres. There are several design choices that are different from pgAdmin (and possibly other database GUI tools). * First of all, we have one instance of pgXplorer handling only one database at a time. So in the unpalatable event that pgXplorer crashes, it brings down only that instance. While one could launch multiple pgAdmins as well, it lists all connections regardless. * A 2-D grid like layout for tables,views and function on the main canvas with search option to quickly highlight a desired item. Very useful when dealing with names in Unicode, where there can be no perceptible alphabetical order (like Japanese). * The SQL editor/console is fully Unicode ready. In pgAdmin, when doing a search/replace with Unicode characters, pgAdmin's editor does not work well. * Editing tables and inserting data in tables handled in a better way than pgAdmin I think. Bulk updates can be done in pgXplorer when a single column is selected. * Copying and pasting data into LibreOffice Calc/Excel with headers. Also, it is quicker than pgAdmin. * A simple table designer for newly created (columnless) tables. These are some salient features of pgXplorer. More features are on the anvil.
  - bartonfink 14y ago
    I'll make it a point to keep giving it a whirl, if only to help out a fellow HN'er. I do agree that there's room for improvement in the desktop DB client world, but I've not run into the problems with e.g. Unicode, that you mentioned. This is probably just my personal use history (I work for Mapquest and spend a large amount of time doing geographic queries). As I said, I'll continue giving it a whirl as best as I can. One thing that I have found virtually intolerable in any DB GUI client I've used is the latency after connection, presumably to load table definitions and other data for display. With psql, I connect and I just start going - the latency is imperceptible. I know that having such metadata readily visible is the reason people use GUI clients, but I find that I frequently don't need that. It's very easy for me to do a \d $tablename to see columns, or select count(1) from ... to get rowcounts as needed. In fact, the cost for doing this is roughly the same as the cost of clicking a table name to expand a schema in a GUI, so really all this sort of behavior does is get in my way. Another thing which I would find enticing would be special attention to displaying query plans. The output of "explain" isn't exactly the clearest, even to someone who's got a pretty good idea how a DB works, and I run explain queries infrequently enough that I have to check the documentation to make sure I'm understanding the result. Even simple clues - e.g. color coding the output so sequential scans are red, for instance - would help. Best of luck with it, though - and if I can help or if you want to bounce anything off me my e-mail is in my profile.

mikegreenberg 14y ago

Hi Davy. I really like the minimalist approach to this app. Install was straight forward (but a little sad a Linux version doesn't exist yet). No complicated shortcuts (I like) and basic functions. It seems hard to screw this up. Sadly, I don't use Postgres and I didn't have any databases sitting around to test it against. If you know of a quick way I could test it against a database, I'd be happy to share more. Otherwise, it looks great!

davyjones 14y ago
Thanks a ton for the kind words Mike. > but a little sad a Linux version doesn't exist yet Working fervently on this. Couple of issues being sorted out now are: a) undesirable window behaviour and 2) packaging for popular linux flavours. >...I didn't have any databases sitting around to test it against. Unfortunately, the easiest way I can think of is to install postgres on your own machine. As a very very low priority item on your schedule, if you can try out pgXplorer on your local database and give some feedback, I would really appreciate it!

bartonfink 14y ago

Davy - I regularly use psql as part of my job, but I gave pgXplorer a whirl. It seems less responsive than psql, but that's a big reason why I use the command line client anyway. One thing I noticed is that you're asking for "Port" twice in the connection properties dialog - I think you mean "Password" in the second instance. I'm probably not your target audience, but I'd like to know - what's the proposition? Why use pgXplorer instead of pgAdmin, for example?

davyjones 14y ago
Thanks a lot for your feedback. I truly appreciate it. Nothing can beat psql in speed in my opinion. pgXplorer carries the overhead of a GUI of course and there is an added level of abstraction when talking to the database. pgXplorer has been built with ease-of-use in mind. > ..you're asking for "Port" twice... Sorry about it. It has been rectified at the source. I shall be updating the installers shortly. > what's the proposition? Why use pgXplorer instead of pgAdmin, for example? Good question. I started with the premise to supplant pgAdmin as the open source GUI tool for postgres. But I don't hold that view anymore. I am thinking of pgXplorer as another open source GUI for postgres. There are several design choices that are different from pgAdmin (and possibly other database GUI tools). * First of all, we have one instance of pgXplorer handling only one database at a time. So in the unpalatable event that pgXplorer crashes, it brings down only that instance. While one could launch multiple pgAdmins as well, it lists all connections regardless. * A 2-D grid like layout for tables,views and function on the main canvas with search option to quickly highlight a desired item. Very useful when dealing with names in Unicode, where there can be no perceptible alphabetical order (like Japanese). * The SQL editor/console is fully Unicode ready. In pgAdmin, when doing a search/replace with Unicode characters, pgAdmin's editor does not work well. * Editing tables and inserting data in tables handled in a better way than pgAdmin I think. Bulk updates can be done in pgXplorer when a single column is selected. * Copying and pasting data into LibreOffice Calc/Excel with headers. Also, it is quicker than pgAdmin. * A simple table designer for newly created (columnless) tables. These are some salient features of pgXplorer. More features are on the anvil.
- bartonfink 14y ago
  I'll make it a point to keep giving it a whirl, if only to help out a fellow HN'er. I do agree that there's room for improvement in the desktop DB client world, but I've not run into the problems with e.g. Unicode, that you mentioned. This is probably just my personal use history (I work for Mapquest and spend a large amount of time doing geographic queries). As I said, I'll continue giving it a whirl as best as I can. One thing that I have found virtually intolerable in any DB GUI client I've used is the latency after connection, presumably to load table definitions and other data for display. With psql, I connect and I just start going - the latency is imperceptible. I know that having such metadata readily visible is the reason people use GUI clients, but I find that I frequently don't need that. It's very easy for me to do a \d $tablename to see columns, or select count(1) from ... to get rowcounts as needed. In fact, the cost for doing this is roughly the same as the cost of clicking a table name to expand a schema in a GUI, so really all this sort of behavior does is get in my way. Another thing which I would find enticing would be special attention to displaying query plans. The output of "explain" isn't exactly the clearest, even to someone who's got a pretty good idea how a DB works, and I run explain queries infrequently enough that I have to check the documentation to make sure I'm understanding the result. Even simple clues - e.g. color coding the output so sequential scans are red, for instance - would help. Best of luck with it, though - and if I can help or if you want to bounce anything off me my e-mail is in my profile.