Hi Chris,
PostgreSQL 8.2 has reached it's official end of life, meaning that now 8.4
> should, I think, be the minimum version we should be targetting for any and
> all new development (including add-ons). There are a number of cases where
> performance is currently limited by us trying to support PostgreSQL 8.3,
> and the biggest example here is the rendering of the menu.
>
Regarding the menu, we decided out of band that we'd create a FAQ item
telling people to load the Menu.sql file from trunk - which we promise to
keep fully backward compatible - if they're on 8.4 and suffering the
performance issue. So that part is "handled".
Myself I thought we required 8.4 for 1.3, but as it turns out both INSTALL
and COMPATIBILITY document that we don't support 8.2 and before (each in
their own way). So, I guess we're indeed stuck with 8.3 for now. I wonder
if we can't make Menu.sql load conditionally depending on the target
system: 8.3/8.4+ especially because the upgrade process will overwrite any
trunk version loaded during patch release upgrades. We already have version
detection in setup.pl; all we need to do is load Menu-84plus.sql when we
detect 8.4 or higher :-)
> 9.2 is on its way soon, and has a few features we will probably find
> extremely useful as we get there. In particular the native JSON support
> might be useful as a replacement for native Pg representation of nested
> types. I don't see that we can even think about requiring 9.2 for 1.4,
> however, since it will be in beta most of the time we are developing.
> However, I would like to consider looking at this for 1.5 despite the fact
> that it is a big jump.
>
Yea. It would be good to know which distributions (and their versions)
offer which postgresql verisons: that'd allow easier decision making.
However, for now, I think we're focussed 1.4. Based on the fact that 1.4
isn't there yet (we still have quite a bit of work to be done) and the
upcoming 9.2 release, 8.3 will probably reach end of life soon after we
release 1.4. If that's true, I think we should use that as a reason to not
support it. Having at least another year of supported life is a good
criterion IMO.
The reason here is that parsing/formatting complex data types for
> PostgreSQL is a pain, and currently DBD::Pg is not able to pick this up.
> We could probably standardize on XML at present, but JSON might be better
> long-run.
>
> What do people think? Obviously any discussion right now needs to be
> pretty tentative.
>
I think supporting 8.3 - while noting the performance issue prominently -
is a good thing for now, especially if we can ship Menu-84plus.sql (ie the
trunk version of Menu.sql). Dropping it in due course also sounds like a
good option - in a next minor release that is.
Bye,
Erik.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
