Re: Introduction

-----Original Message-----
From: Mark A. Taff [mailto:mark(at)libertycreek(dot)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.