Forum OpenACS Q&A: ACS approval of interoperability
For instance, I want to use Postgres 7.3.3 and I'm using version 4.6 of ACS. Is someone specifically testing this circumstance or does the community wait until someone just does it and lets the rest of the community know?
If there is some place to go on this site that contains that information? Thanks.
However ... the toolkit's big and we don't have regression or coverage tests (both things I'd like to have happen in the next few months) so testing's a big job.
I've been using PG 7.3.2 for all my OpenACS development work for a few months now so I can say that the core and basic .LRN functionality work with 7.3.x just fine.
Don or anyone else familiar with PG innards:
Before I go off to upgrade my PG 7.3.2 installation to the new 7.3.3 release, does anyone have any idea whether the statement below from the PG folks, might point to any compatibility problems with OACS 4.6.3?
"This release [PG 7.3.3], as with all minor releases, does not *require* a dump/reload to be upgraded to, but there is a change to pg_proc, as pertains timestamptz_izone that only takes effect after an initdb ..."
Found the stuff below. Maybe there is more information in the new release itself. I'll post anything else I find...
"...We also saw a few changes to time oriented data handling, some of which was related to some recent discussions on the -general list. Now when a TIMESTAMP, TIME, or INTERVAL precision is specified larger than our implementation limits, a NOTICE is issued and we use the max supported value. Previously this would have resorted in an error, but the change was needed to allow easy porting from pre-7.3 releases where the limits were higher. We also now allow 60 seconds fields of TIMESTAMP, TIME, or INTERVAL input values. This is actually appropriate for spec compliance and will also help in porting from older pg_dump files."
"Tom Lane added in some code to add code to test for unknown timezone names (following some ideas from Ross Reedstrom a couple months back) and to detect timezones that are using leap-second timekeeping. Along with this he also made DecodePosixTimezone() a tad more robust. Tom also finished removing the support for autocommit from the back end based on recent discussions, though there is still a need to support this on the client side in lippq."