Thread: Slony scripts
Hi Andreas I was thinking about including the Slony scripts with the pgAdmin/pgInstaller packaging. To save me rooting through the code to find it, where does we look for them at the moment? Also, how do we handle different Slony versions? Scripts in a subdirectory someplace, or do we rename them so they don't clash. Or do we say you can only create clusters in the version that you have installed the scripts for? Cheers, Dave.
Dave Page wrote: >Hi Andreas > >I was thinking about including the Slony scripts with the >pgAdmin/pgInstaller packaging. To save me rooting through the code to >find it, where does we look for them at the moment? Also, how do we >handle different Slony versions? Scripts in a subdirectory someplace, or >do we rename them so they don't clash. Or do we say you can only create >clusters in the version that you have installed the scripts for? > > See slony path in options. We don't maintain different versions, but assume that we're always using the latest. When joining a cluster or upgrading a cluster (not the first), all ddl info is extracted from existing clusters, so no scripts are needed. dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster schema reengineering code needs to be extracted to a standalone class. It's also needed for initial schema creation as duplicate from an existing source db, e.g. for new replication slaves. Should be a context menu option opening the Query Tool with the ddl script for review. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 19 September 2005 15:39 > To: Dave Page > Cc: pgAdmin Hackers > Subject: Re: Slony scripts > > See slony path in options. OK - needs a helpfile update ethough :-p > We don't maintain different versions, but assume that we're > always using > the latest. When joining a cluster or upgrading a cluster (not the > first), all ddl info is extracted from existing clusters, so > no scripts > are needed. > dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster > schema reengineering code needs to be extracted to a > standalone class. > It's also needed for initial schema creation as duplicate from an > existing source db, e.g. for new replication slaves. Should > be a context > menu option opening the Query Tool with the ddl script for review. OK, well I won't bother shipping any Slony scripts at all with pgAdmin then, and I'll only add them top pgInstaller when Slony for Windows ships - that way it's up to the admin to ensure he has the correct scripts for the installed version, except in the case when they all come from the same place. Cheers, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>Sent: 19 September 2005 15:39 >>To: Dave Page >>Cc: pgAdmin Hackers >>Subject: Re: Slony scripts >> >>See slony path in options. > > > OK - needs a helpfile update ethough :-p > > >>We don't maintain different versions, but assume that we're >>always using >>the latest. When joining a cluster or upgrading a cluster (not the >>first), all ddl info is extracted from existing clusters, so >>no scripts >>are needed. >>dlgRepClusterUpgrade implementation still to be coded; dlgRepCluster >>schema reengineering code needs to be extracted to a >>standalone class. >>It's also needed for initial schema creation as duplicate from an >>existing source db, e.g. for new replication slaves. Should >>be a context >>menu option opening the Query Tool with the ddl script for review. > > > OK, well I won't bother shipping any Slony scripts at all with pgAdmin > then, and I'll only add them top pgInstaller when Slony for Windows > ships - that way it's up to the admin to ensure he has the correct > scripts for the installed version, except in the case when they all come > from the same place. Yup. Could be written to HKLM/Software/pgAdmin III /SlonyPath, and read from there as default if HKCU/Software/pgAdmin III /SlonyPath is not set. Regards, Andreas