[OPEN-ILS-DEV] Postgres 8.3, small patches, and questions.

[Mike Rylander]

On Fri, Feb 29, 2008 at 10:27 AM, Reuben Pasquini <rdp0004 at auburn.edu> wrote:
> Hello!
>
>  I'm working through get Evergreen-ILS-1.2.1.4/OpenSRF-0.9 up and
>  running
>  on an Ubuntu Gutsy box.
>  I made the mistake of installing postgres 8.3 without realizing that
>  OpenILS
>  depends on the tsearch2 extention that has been modified in a
>  non-backward
>  compatible way in postgres 8.3.
>          http://www.postgresql.org/docs/8.3/static/tsearch2.html
>  Has anyone looked into porting
>
>  Evergreen-ILS-1.2.1.4/Open-ILS/src/sql/Pg/000.english.pg82.fts-config.sql
>  to postgres 8.3, or is that an open task ?

It's currently open.  It's on my to-do list, but since PG 8.3 is still
just barely out of RC it isn't a high priority.  We certainly wouldn't
turn down a patch, though!

>
>  Another 8.3 related patch will be required to lib_setup.cgi -
>  8.3 doesn't like doing a 'LIKE' search against an integer column, so
>     actor::org_unit->search_like( {parent_ou=>'%' ...
>  bombs out with an error:
>

[snip]

>  -------------
>
>  I threw this patch on to get things working - there's probably a
>  cleaner way to do it:
>

The query is looking for every node /but/ the root node, so I think  a
variation on { parent_ou => { '!=' => undef } } is what we'll want.
Of course, the Class::DBI docs don't mention that spell for "is not
null", so an alternative is to filter the return of your modification
where the parent_ou field is not undef.
[snip]

>  -------------
>
>  Anyway, I got pretty far along in the setup before realizing the
>  tsearch2 problem.
>  Along the way I had a screwed up libdbi + libdbdpgsql build which
>  broke
>  oils_cstore.so, which prevented auotgen.sh from completing.
>  In the process of tracking down the oils_cstore problem I patched
>  several of the autogen.sh perl scripts to deal with error conditions
>  a little better.  I'm not sure if all these patches make sense -
>  the patches mostly modify the code to work around undefined
>  variables, but it may be better to modify the code to fail
>  with an informative error message if the situation is that the
>  variable should always be defined.
>  Anyway - here are a few patches:
>

Thanks, though your instincts were correct.  Generally if you're
getting an undefined variable error then there's a bigger problem
somewhere.  I'll look at these in terms of beefing up the error
messages.

[snip]

>
>  Anyway, please let me know if anyone has a Postgres 8.3 .sql file
>  I can use, otherwise I'll get to work on redoing my postgres install
>  with 8.2.

For testing, and for stability's sake (more than just tsearch changes
...), I'd suggest sticking with 8.2 for now.

>  Let me know if there's some place else that I should be sending these
>  patches.

Sending patches here is fine, but as attachments and as svn diffs
would ease things a little on this end ... I may need to update the
docs to be more explicit about that.

Thanks, Reuben!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com