Thread: Interesting Issues

Interesting Issues

From
"Rod Taylor"
Date:
PGAdmin doesn't allow a user to create an inherited table without
additional columns of sometype, as a work around I added a nullable
single bit column to my table.

Database publishing wizard doesn't remember 'production databases'
from one time to another.


The historical information (RCS) is quite interesting.  Is there any
chance that the 'Publishing' wizard will be able to publish diffs
between the database you're publishing to and the test version(s)?  As
a step between these, the ability to dump (in SQL form) the difference
between one version and another (that is, the commands to bring the
one up to the level with another) would be extreamly useful.   Of
course, both have to be managable without any dataloss.
--
Rod Taylor

Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.



Re: Interesting Issues

From
Dave Page
Date:

> -----Original Message-----
> From: Rod Taylor [mailto:rbt@zort.ca]
> Sent: 11 February 2002 02:26
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] Interesting Issues
>
>
> PGAdmin doesn't allow a user to create an inherited table
> without additional columns of sometype, as a work around I
> added a nullable single bit column to my table.

No. I don't suppose it's something that many people try to do :-)
Added to TODO.

> Database publishing wizard doesn't remember 'production
> databases' from one time to another.

Added to TODO.

> The historical information (RCS) is quite interesting.  Is
> there any chance that the 'Publishing' wizard will be able to
> publish diffs between the database you're publishing to and
> the test version(s)?  As a step between these, the ability to
> dump (in SQL form) the difference between one version and
> another (that is, the commands to bring the
> one up to the level with another) would be extreamly useful.   Of
> course, both have to be managable without any dataloss.

Unfortunately this is not possible with the current system as the revision
control only stores the SQL to create the object, not what was used to
update it - which might not even be possible if it was modified in a dump
file or by dropping and recreating it.

The only diff we could do would be a traditional text diff which would be
useless.

Regards, Dave.

Re: Interesting Issues

From
"Rod Taylor"
Date:
> > The historical information (RCS) is quite interesting.  Is
> > there any chance that the 'Publishing' wizard will be able to
> > publish diffs between the database you're publishing to and
> > the test version(s)?  As a step between these, the ability to
> > dump (in SQL form) the difference between one version and
> > another (that is, the commands to bring the
> > one up to the level with another) would be extreamly useful.   Of
> > course, both have to be managable without any dataloss.
>
> Unfortunately this is not possible with the current system as the
revision
> control only stores the SQL to create the object, not what was used
to
> update it - which might not even be possible if it was modified in a
dump
> file or by dropping and recreating it.
>
> The only diff we could do would be a traditional text diff which
would be
> useless.

Sorry, I was making the assumption that the production database was
already identical to another version in the past.  Ie.  Production is
version 10, test is version 22.  Could one not apply all statements
from 10 through 22 and end up with both databases being of the same
level?

As long as the alterations are non-destructive (ie.  uses alter table
rather than dropping and re-creating the table while losing data)
which appears to be true.  The only difference between a production,
test and development systems would be their current version.  If the
RCS information was stored in each, it should be straight forward to
determine which was where.

I wonder if work has a copy of Visual Basic around somewhere.  This is
a feature that benifits them quite a bit and it's about time I started
doing to some windows based development.  Besides, I'd love to see the
thought behind my Postgresql Autodoc tool be integrated into PGAdmin.


Re: Interesting Issues

From
Dave Page
Date:

> -----Original Message-----
> From: Rod Taylor [mailto:rbt@zort.ca]
> Sent: 11 February 2002 14:19
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Interesting Issues
>

<snip>

> > The only diff we could do would be a traditional text diff which
> would be
> > useless.
>
> Sorry, I was making the assumption that the production
> database was already identical to another version in the
> past.  Ie.  Production is version 10, test is version 22.
> Could one not apply all statements from 10 through 22 and end
> up with both databases being of the same level?

The old pgAdmin project had exactly this feature. It logged all 'schema
update' queries against the current version number (which could be changed
at will) and could then produce SQL scripts of all the updates from any
previous to the current version. As no-one ever admitted to using this
feature it was one of those the never made it to pgAdmin II.

In reality, it probably wouldn't be too difficult to put it in there again
as all SQL queries pass through a single function in the pgSchema library
anyway, but I'm not sure if I'd have the time to do it.

>
> I wonder if work has a copy of Visual Basic around somewhere.

We welcome patches if you want to work on this :-)

>  This is a feature that benifits them quite a bit and it's
> about time I started doing to some windows based development.
>  Besides, I'd love to see the thought behind my Postgresql
> Autodoc tool be integrated into PGAdmin.

Was it you that suggested a query recording system so the developer could
record the queries executed in a session to a script? That is actually done
and in CVS now, and could (the guts of it anyway) form the basis for such
enhancments.

Regards, Dave.