Forum OpenACS Q&A: Re: Postgresql 7.3 packaged...

Collapse
Posted by Don Baccus on
The bit stuff doesn't bother me too much, because our use is isolated to a few functions, though introducing new functions that need to be quoted because they clash with something else seems somewhat braindead to me.

Functions that accept integers into a varchar are just plain wrong, right?  How many such functions exist?

We can expect 7.4 to introduce even more incompatibilities :)

Collapse
Posted by Bart Teeuwisse on

There are a few of functions that accept integers as a varchar parameter. Here's the list:

  • acs_attribute__create_attribute (acs-kernel)
  • content_module__new (cms)
  • cm_form_widget__set_attribute_param_value (cms)

/Bart

Collapse
Posted by russ m on

the need to do bitstring casts like that is a bug in postgres that by the sound of it appeared for 7.3 and will be fixed for 7.4 (but not before since it will require an initdb)... annoying...

reference here - http://archives.postgresql.org/pgsql-hackers/2002-10/msg00568.php

Collapse
Posted by Bart Teeuwisse on

Patches to make OpenACS PG 7.3 compatible have been applied to the OpenACS CVS HEAD. Mind you you'll still need to apply the following patch to PG 7.3 itself:


*** src/backend/optimizer/plan/planner.c.orig    Tue Sep 24 14:38:23 2002
--- src/backend/optimizer/plan/planner.c    Thu Dec  5 16:32:21 2002
***************
*** 330,339 ****
              * nothing will happen after the first time.  We do have to be
              * careful to copy everything we pull up, however, or risk
              * having chunks of structure multiply linked.
              */
             subquery->jointree = (FromExpr *)
                 pull_up_subqueries(subquery, (Node *) subquery->jointree,
!                                    below_outer_join);
 
             /*
              * Now make a modifiable copy of the subquery that we can run
--- 330,343 ----
              * nothing will happen after the first time.  We do have to be
              * careful to copy everything we pull up, however, or risk
              * having chunks of structure multiply linked.
+              *
+              * Note: 'false' is correct here even if we are within an outer
+              * join in the upper query; the lower query starts with a clean
+              * slate for outer-join semantics.
              */
             subquery->jointree = (FromExpr *)
                 pull_up_subqueries(subquery, (Node *) subquery->jointree,
!                                    false);
 
             /*
              * Now make a modifiable copy of the subquery that we can run
***************
*** 513,518 ****
--- 517,536 ----
      * quals of higher queries.
      */
     if (expression_returns_set((Node *) subquery->targetList))
+         return false;
+ +     /*
+      * Don't pull up a subquery that has any sublinks in its targetlist,
+      * either.  As of PG 7.3 this creates problems because the pulled-up
+      * expressions may go into join alias lists, and the sublinks would
+      * not get fixed because we do flatten_join_alias_vars() too late.
+      * Eventually we should do a complete flatten_join_alias_vars as the
+      * first step of preprocess_expression, and then we could probably
+      * support this.  (BUT: it might be a bad idea anyway, due to possibly
+      * causing multiple evaluations of an expensive sublink.)
+      */
+     if (subquery->hasSubLinks &&
+         contain_subplans((Node *) subquery->targetList))
         return false;
 
     /* 

My advise is to wait for a PG 7.3.1 release and the release of OpenACS 4.6 after which the 4.6 branch will be merged to the CVS HEAD.

/Bart