Well, got the bugger: The problem is a Postgres 7.4 vs. 8.0 issue, sitting in acs-content-repository/postgres/content-type.sql. The content-repository code in the current oacs-5.2.2 produces rules that insert for derived datatypes the tuples in the wrong order. The insert for xowiki_plain_page triggers the
fault mentioned above, since the key inserted into derived type (xowiki_plain_page) is not yet in the supertype (xowiki_page)
xowiki_plain_page_r AS
ON INSERT TO xowiki_plain_pagei DO INSTEAD
...
INSERT INTO xowiki_plain_page (ppage_id)
VALUES (cr_dummy.val);
INSERT INTO xowiki_page (page_id)
VALUES (cr_dummy.val);If the order is changed, it works fine
xowiki_plain_page_r AS
ON INSERT TO xowiki_plain_pagei DO INSTEAD
...
INSERT INTO xowiki_page (page_id)
VALUES (cr_dummy.val);
INSERT INTO xowiki_plain_page (ppage_id)
VALUES (cr_dummy.val);I played as well with deferring the checks, but this did not seem to work.
dave, you find the fixed rule generator in george:~gustafn/create-rule.sql
Most likely this will fix the bug #2810 as well
https://openacs.org/bugtracker/openacs/bug?f%5fcomponent=56190&format=table&f%5fstate=7&bug%5fnumber=2810&project%5fid=56106
The same should happen with all other apps with derived types using the postgres rules for updating the views. But i guess, there are not to many apps stressing the CR in this respect as much as xowiki....
I did not upgrade the xowiki on the test-server, since we forgot the permissions for upgrading xotcl-core. But i am quite confident, that things will work nicely now. On oacs.org, updating the rule-generator +
select content_type__refresh_view('::xowiki::PlainPage') from dual
select content_type__refresh_view('::xowiki::PageTemplate') from dual
select content_type__refresh_view('::xowiki::PageInstance') from dual
select content_type__refresh_view('::xowiki::Object') from dual+ reboot should do the trick for xowiki.
