Обсуждение: 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. 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.
> -----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.
> > 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.
> -----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.