[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Kexi-devel] libpqxx 2.6.9 breaks kexi's pqxx driver
From:       Adam Pigg <piggz1 () gmail ! com>
Date:       2007-02-11 12:51:47
Message-ID: 200702111251.47552.adam () piggz ! co ! uk
[Download RAW message or body]

On Saturday 10 February 2007 23:51:39 Jarosław Staniek wrote:
> Michael Nottebrock wrote:
> >> > I'll take a look, but give me a few days
> >>
> >> We're using public pqxx's API, right?
> >> Michaael, what pqxx version are you talking about? If they broke source
> >> compatibility in a minor release, then it's not our fault...
> >
> > To quote their release notes:
> >
> > "Many things have changed. Bugs have been fixed, new features
> > have been introduced. But most importantly, we're really retiring
> > the old 1.x-style libpqxx API now. This API (where upper-case letters
> > were still used in function names and such) has been supported for
> > more than three years in the interest of backwards compatibility,
> > but has been marked as obsolete all this time."
>
> Michael, thanks for the info.
>
> I consider these API changes as ugly step. Ugly enough to make us depend on
> <=2.6.8 and add a notice to packagers about avoiding packaging 2.6.9. I am
> suggesting to go this way.
>
> Moreover, with (the last official, before 2.0!) release coming next week,
> we have no time and power to test such a nontrivial jump, and this is even
> against of our policy related to minor releases. Example: mysql client lib
> can be upgraded on a target system without negative implications to KexiDB.
>
> Also note that pqxx usage in Kexi 2.0 will be most likely dropped in favour
> of libpq. It has become more and more hard to wrap one C++ API (pqxx)
> within another (kexidb) without any clear benefit, but with code
> obfuscated. For instance, we do not need 'intelligent' db cursors coming
> from pqxx because KexiDB impelements them from scratch. Pqxx can be nice to
> use in apps, but again: it's hard to wrap and I'd say it will be even
> harder as pqxx become more object-oriented. That's not even pqxx fault.
> In 1.6.x, despite superiority of postgesql as a backend, mysql support is
> better, more stable than pgsql.
>
Just wondering, in what ways is mysql support better? does the pg driver not 
implement some things?

> Please correct me, but I still do not believe the developers decided not to
> jump to 2.7 or even 3.0 version before such a change (ABI is thus badly
> broken as well). It's like TT would DROP Qt3 Support module one night...
>
> Summing, up I propose to do nothing in terms of coding (perhaps except a
> configure check against the 2.6.9 version).


_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]