Thread: Introduction

-----Original Message-----
From: Mark A. Taff [mailto:mark@libertycreek.net]
Sent: 14 February 2002 17:28
To: pgadmin-hackers
Subject: [pgadmin-hackers] Introduction

Howdy!

 

I am interested in helping to develop pgAdmin.

 

By way of e-introduction, my name is Mark Taff.  I am a web and database developer living near Seattle, Washington, USA.

 

Hi, I'm Dave!! :-) (guess you already know that though...).

 There are a number of features/improvements to pgAdmin I would like to see (and am willing to work on!), but I don't want to waste my time, so I thought it best to run them by you guys and get your feedback before I do anything.  I don't want to be working at cross-purposes with the other developers.  So, in no particular order...

 

 

1. The treeview should automatically show newly created objects if other objects of the same type are currently displayed.  The user should never have to `refresh below selection` unless they are in a multi-author environment, and even then it may make sense to periodically (during low cpu use) check the server for objects we aren't aware of.  
   
   When an object is created or dropped through IDE, the treeview *is* updated, however, if you execute SQL manually, or another developer creates something it will not be. I'm not convinced that you will find a good way to solve this problem. Of course, with software like SQL Server, the management console is much more tightly integrated with the server. pgAdmin users are running ODBC connections, often over slow connections so this level of integration is not possible.
    
2. I would like to see the treeview root item be `servers`, which would have sub nodes for different servers.  I work in a multi-server environment, and it would be nice to be able to work with objects on multiple servers at the same time.  This would open up the possibility of easily `copying` objects from one server to another.  
   
   Agreed. This will require significant reworking of the higher levels of pgSchema. I did look at it a month or so back and left it when I realised how much work was involved.
   
3. The re-engineered SQL code is nice, but it has limited usefulness.  I do most of my work using the execute sql window because in good coding tradition, I like to leave lots of comments about just what the heck is going on.  This is most important for functions (and function-like objects).  I also like to save the SQL for each object as both an individual .sql file and as part of a global class and object-type class files.  This modular approach allows me to pick and choose objects to quickly build a new database.  To implement such a creature, I would suggest an SQL IDE so to speak, much like the VBA editor used in Office applications.  Part of this is also the desired ability to right-click an object in the tree and to be able to edit _my_ sql code (with comments) rather than re-engineered SQL code.  I am keenly interested in making this a reality.  
   
   The re-engineered SQL is essential to the Revision Control features. The downside with the approach you suggest is that it requires centralised storage of all the SQL - one of the things people often complained about with pgAdmin I was the tables it created in each database. The other side of this, is that most people probably use pgAdmin so they don't have to worry about authoring the SQL themselves, so such a feature would probably be of limited interest.
     
4. I would like to see a query designer with features like the one in MS SQL Server 2000.  This requires the graphical relationship plugin to be finished first, as it would have to be an optional pane.  The actual interface isn't really important.  What I find important is having relationships, objects and their properties, an sql pane, and a results pane all in one place.  Probably the only way to make that happen is with a full-size form in addition to the main form.  
   
   Sounds good.
    
5. Dependencies, dependencies, dependencies!  On of my favorite features of SQL Server is that it tells me when I am trying to delete an object that other objects depend on.  I realize that PostgreSQL doesn't track such dependencies, but that doesn't mean we can't.  We could create a series of PostgreSQL triggers/rules that would create/update a dependencies table on object creation/deletion.  We would then query this relation prior to dropping an object.  This is probably the cleanest approach.  This shouldn't be too hard to implement, as PostgreSQL is kind enough to store object information in selectable tables (hence triggerable, I think).  As this would be making some serious system changes to the server, we should get user permission before creating these rules and triggers on the server, IMO.  
   
   The last code we worked on for pgAdmin I tracked dependencies. It was very complex, and there were many issues we could not resolve satisfactorily. For example, it's very difficult to figure out what objects a PL function written in language X is dependant on.
   
   We are not currently re-implementing this code, for that reason, and because there has been talk of PostgreSQL having a pg_dependencies table soon anyway.
   
6. The log window needs to have a close button to allow it to be closed.  If you are silly, as I am sometimes, you set the log window to always on top positioned in the center of the screen space.  The next time you open pgAdmin, you can't do anything because the tips form is modal and hidden beneath the log window.  I have to call myself silly, then use task manager to forcibly kill pgAdmin, then edit the registry to change the log window options.  
   
   The 'Show Log Window' option on the 'View' menu is your friend!! Feel free to add a close button, but please make sure it works with that menu option appropriately.

 

 Happy hacking!

Regards, Dave.

----- Original Message -----

From: Dave Page

To: 'Mark A. Taff' ; pgadmin-hackers

Sent: Thursday, February 14, 2002 2:58 PM

Subject: Re: [pgadmin-hackers] Introduction

 

-----Original Message-----
From: Mark A. Taff [mailto:mark@libertycreek.net]
Sent: 14 February 2002 17:28
To: pgadmin-hackers
Subject: [pgadmin-hackers] Introduction

Howdy!

 

I am interested in helping to develop pgAdmin.

 

By way of e-introduction, my name is Mark Taff.  I am a web and database developer living near Seattle, Washington, USA.

 

Hi, I'm Dave!! :-) (guess you already know that though...).

 There are a number of features/improvements to pgAdmin I would like to see (and am willing to work on!), but I don't want to waste my time, so I thought it best to run them by you guys and get your feedback before I do anything.  I don't want to be working at cross-purposes with the other developers.  So, in no particular order...

 

 

1. The treeview should automatically show newly created objects if other objects of the same type are currently displayed.  The user should never have to `refresh below selection` unless they are in a multi-author environment, and even then it may make sense to periodically (during low cpu use) check the server for objects we aren't aware of.  
   
   When an object is created or dropped through IDE, the treeview *is* updated, however, if you execute SQL manually, or another developer creates something it will not be. I'm not convinced that you will find a good way to solve this problem. Of course, with software like SQL Server, the management console is much more tightly integrated with the server. pgAdmin users are running ODBC connections, often over slow connections so this level of integration is not possible.
    
2. I would like to see the treeview root item be `servers`, which would have sub nodes for different servers.  I work in a multi-server environment, and it would be nice to be able to work with objects on multiple servers at the same time.  This would open up the possibility of easily `copying` objects from one server to another.  
   
   Agreed. This will require significant reworking of the higher levels of pgSchema. I did look at it a month or so back and left it when I realised how much work was involved.
   
3. The re-engineered SQL code is nice, but it has limited usefulness.  I do most of my work using the execute sql window because in good coding tradition, I like to leave lots of comments about just what the heck is going on.  This is most important for functions (and function-like objects).  I also like to save the SQL for each object as both an individual .sql file and as part of a global class and object-type class files.  This modular approach allows me to pick and choose objects to quickly build a new database.  To implement such a creature, I would suggest an SQL IDE so to speak, much like the VBA editor used in Office applications.  Part of this is also the desired ability to right-click an object in the tree and to be able to edit _my_ sql code (with comments) rather than re-engineered SQL code.  I am keenly interested in making this a reality.  
   
   The re-engineered SQL is essential to the Revision Control features. The downside with the approach you suggest is that it requires centralised storage of all the SQL - one of the things people often complained about with pgAdmin I was the tables it created in each database. The other side of this, is that most people probably use pgAdmin so they don't have to worry about authoring the SQL themselves, so such a feature would probably be of limited interest.
     
4. I would like to see a query designer with features like the one in MS SQL Server 2000.  This requires the graphical relationship plugin to be finished first, as it would have to be an optional pane.  The actual interface isn't really important.  What I find important is having relationships, objects and their properties, an sql pane, and a results pane all in one place.  Probably the only way to make that happen is with a full-size form in addition to the main form.  
   
   Sounds good.
    
5. Dependencies, dependencies, dependencies!  On of my favorite features of SQL Server is that it tells me when I am trying to delete an object that other objects depend on.  I realize that PostgreSQL doesn't track such dependencies, but that doesn't mean we can't.  We could create a series of PostgreSQL triggers/rules that would create/update a dependencies table on object creation/deletion.  We would then query this relation prior to dropping an object.  This is probably the cleanest approach.  This shouldn't be too hard to implement, as PostgreSQL is kind enough to store object information in selectable tables (hence triggerable, I think).  As this would be making some serious system changes to the server, we should get user permission before creating these rules and triggers on the server, IMO.  
   
   The last code we worked on for pgAdmin I tracked dependencies. It was very complex, and there were many issues we could not resolve satisfactorily. For example, it's very difficult to figure out what objects a PL function written in language X is dependant on.
   
   We are not currently re-implementing this code, for that reason, and because there has been talk of PostgreSQL having a pg_dependencies table soon anyway.
   
6. The log window needs to have a close button to allow it to be closed.  If you are silly, as I am sometimes, you set the log window to always on top positioned in the center of the screen space.  The next time you open pgAdmin, you can't do anything because the tips form is modal and hidden beneath the log window.  I have to call myself silly, then use task manager to forcibly kill pgAdmin, then edit the registry to change the log window options.  
   
   The 'Show Log Window' option on the 'View' menu is your friend!! Feel free to add a close button, but please make sure it works with that menu option appropriately.

 

 Happy hacking!

 

Regards, Dave.

-----Original Message-----
From: Mark A. Taff [mailto:mark@libertycreek.net]
Sent: 14 February 2002 21:03
To: Dave Page; pgadmin-hackers
Subject: RE: [pgadmin-hackers] Introduction
 

2.    I would like to see the treeview root item be `servers`, which would have sub nodes for different servers.  I work in a multi-server environment, and it would be nice to be able to work with objects on multiple servers at the same time.  This would open up the possibility of easily `copying` objects from one server to another.  

Agreed. This will require significant reworking of the higher levels of pgSchema. I did look at it a month or so back and left it when I realised how much work was involved.

 

MT: That occurred to me as well.  That is one of the major reasons I wanted to be sure about the future direction before I even considered trying to write the code. 

 

DP: Thinking about it, you would end up touching all the Plugins and just about every form in pgAdmin as well.

 

3.    The re-engineered SQL code is nice, but it has limited usefulness.  I do most of my work using the execute sql window because in good coding tradition, I like to leave lots of comments about just what the heck is going on.  This is most important for functions (and function-like objects).  I also like to save the SQL for each object as both an individual .sql file and as part of a global class and object-type class files.  This modular approach allows me to pick and choose objects to quickly build a new database.  To implement such a creature, I would suggest an SQL IDE so to speak, much like the VBA editor used in Office applications.  Part of this is also the desired ability to right-click an object in the tree and to be able to edit _my_ sql code (with comments) rather than re-engineered SQL code.  I am keenly interested in making this a reality.  

The re-engineered SQL is essential to the Revision Control features. The downside with the approach you suggest is that it requires centralised storage of all the SQL - one of the things people often complained about with pgAdmin I was the tables it created in each database. The other side of this, is that most people probably use pgAdmin so they don't have to worry about authoring the SQL themselves, so such a feature would probably be of limited interest.

 

MT: It hadn't even occurred to me store the SQL in the database.  I was planning on storing it in local .sql files.  I consider it a benefit to have the data stored outside of the database.  That way if the database dies a horrible and sudden death, I still have my code.  I guess all I really need such a creature for is writing complex stored procedures.  I was thinking of adding this capability as opposed to replacing the re-engineered code with this.  I'll have to mull this over a bit more.

 
DP: The database is the *only* place such data can be stored as it is the only place that all developers of a single database can be assumed to have access to.

 

Anyhoo, if you're using it primarily for stored procedures, then there shouldn't be a problem anyway as the code of a PL function *never* gets altered by pgAdmin or PostgreSQL - it can't, because neither have any builtin knowledge of the language. This means you can comment your code as much as you like and not lose those comments. With PostgreSQL 7.2 you can edit those functions using pgAdmin as well, and in a future version of pgAdmin, I intend to make the highlight box (the textbox that you write functions in) be detachable from the parent window, into a resizable edit window of it's own.

Gotta go now, I'm falling asleep on my laptop :-)

 

Dave.