Chris,
On 2011-09-24 03:36, Chris Travers wrote: > On Fri, Sep 23, 2011 at 10:15 AM, Philip Rhoades <[email protected]> > wrote: >> Chris, >> >> >> On 2011-09-24 03:09, Chris Travers wrote: >>> On Fri, Sep 23, 2011 at 10:06 AM, Philip Rhoades >>> <[email protected]> >>> wrote: >>>> Chris, >>>> >>> >>>> It is not really critical for me - I just thought it would be nice >>>> to >>>> have all packages that are required to be installed in one go (I >>>> would >>>> normally have PG installed already anyway). >>>> >>> The major reason to consider a separate package would be that 1.3 >>> relies on the contrib modules which are packaged separately. So >>> having something which requires both the server and the contrib >>> modules to be installed might be nice (with .debs, one can list the >>> dependencies as optional, but that's not an option with rpms). >> >> >> OK, sounds good. >> >> >>> So I am thinking of just creating a separate rpm with the >>> additional >>> dependencies. this isn't such an issue beyond 1.3, because it >>> isn't >>> clear we need the contrib modules if we are willing to require Pg >>> 8.4 >>> or higher. >> >> >> Pg 9.x is not in the lsmb roadmap and it will probably be the >> standard >> soon . . how many using lsmb have talked about DB replication etc? >> > 9.x is supported. 1.3.x is tested mostly currently on 8.3-9.0. I > don't know of any reason why 9.1 would cause issues. > > But supporting and requiring are different. 1.3 doesn't use any new > features added since 8.1, so that's the minimum version it can > theoretically run on. 8.1 is only supported through a few vendors > anymore and so given that security fixes are not available through > postgresql.org anymore, I don't officially support it. A lot of > development/testing occurred on 8.2. I don't advertise support on > 8.2 > because it is nearing end of life, and 8.3 makes it easier to add > full > text indexing in a forward-compatible way. Unofficially, I believe > it > runs. > > Going forward though, and requiring 8.4 for 1.4 would allow us to use > WITH RECURSIVE instead of connectby(), and thus we can get rid of > both > the tsearch2 and tablefunc dependencies. That all sounds good - I am just doing my own thing now so I don't have to worry about client's server stability or anything anymore so for myself I will just use whatever the current version of Fedora uses - and that is still 8.4 at the moment. It is not likely I will have to think about DB replication again either. Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: [email protected] ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
