On Tue, 13 Aug 2002, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Marc G. Fournier writes: > >> Okay, but if we are going to pull libpqxx, what about the other lib's too? > > > Certain things apply to libpqxx that don't all apply to the others libs: > > It is maintained and developed independently anyway. It's new and not > > integrated yet. It's a different programming language. It's a > > non-standard interface. It's big. > > > If there is ever going to be any motion toward separating parts of the > > source tree, libpqxx has to be the start. > > I agree with Peter's points here --- but separating libpqxx alone isn't > the right answer. We need to pull both libpqxx and libpq++ at the same > time, else we'll be creating the wrong impression about what we think of > libpqxx. > > Another thing that would be reasonable to separate out in the near term > is interfaces/perl5, which is not favored over the DBI driver. > > JDBC and ODBC are almost separate projects already, and perhaps should > be cut loose so they can have their own release cycles. I'd defer to > the maintainers of those interfaces about what they want to do, though. > > I'm not particularly concerned about removing the other interfaces such > as libpgtcl and python. They're not large and they're (AFAIK) the only > alternatives for their languages.
god, ppl finally catch up *roll eyes* as for libpgtcl and python ... python is seperately maintained by D'Arcy Cain, so that one isn't a problem ... but who is maintaining libpgtcl? libpq++ was "the only alternatives for their language" until libpqxx came along, and from talking to J, libpqxx started off as an attempt to "fix the bugs" in libpq++ that turned out to be so numerous that starting from scratch was easier ... Basically, if somethign doesn't have a maintainer, we're promoting something we shouldn't be in the first place ... ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
