Migration questions for upcoming 8.3 release and fts

Hi all;

I know -hackers is the preferred place to discuss beta releases, but I
suspect that this is a further-reaching wuestion among the general
community than is typical so I am posting it here.

I have been looking at the changes expected for 8.3 and have noticed
that tsearch2 has been modified and merged with core. I think this is a
great idea, but it poses problems for applications which must run both
both on 8.2 and 8.3 with fts capabilities.

I am trying to determine the best way forward so that LedgerSMB can
support 8.3 as soon as it is released. Reading through various email
list archives it looks like the function names have changed. I guess I
am trying to determine the best way forward.

1) How safe is it likely to be to create a set of functions in 8.3
which mimic 8.2/tsearch2 interfaces? Is this likely to create any
serious conflicts? Would such a project be sufficiently useful that a
pg_foundry project might be helpful?

2) If this is a problem, is the community interested in (possibly as a
pg-foundry project) an abstraction layer for supporting both sets of
interfaces?

Best Wishes,
Chris Travers

On Wednesday 24 October 2007 21:10, Chris Travers wrote:
> Hi all;
>
> I know -hackers is the preferred place to discuss beta releases, but I
> suspect that this is a further-reaching wuestion among the general
> community than is typical so I am posting it here.
>
> I have been looking at the changes expected for 8.3 and have noticed
> that tsearch2 has been modified and merged with core. I think this is a
> great idea, but it poses problems for applications which must run both
> both on 8.2 and 8.3 with fts capabilities.
>
> I am trying to determine the best way forward so that LedgerSMB can
> support 8.3 as soon as it is released. Reading through various email
> list archives it looks like the function names have changed. I guess I
> am trying to determine the best way forward.
>
> 1) How safe is it likely to be to create a set of functions in 8.3
> which mimic 8.2/tsearch2 interfaces? Is this likely to create any
> serious conflicts? Would such a project be sufficiently useful that a
> pg_foundry project might be helpful?
>
> 2) If this is a problem, is the community interested in (possibly as a
> pg-foundry project) an abstraction layer for supporting both sets of
> interfaces?
>

The talk is that the tsearch2 contrib module will be redone to access the
built-in functions for 8.3. If this is done, backwards compatability should
be pretty easy to work out. Help in that area would be greatly appreciated
(and it may not get done if no one offers to help)

That said, I think it is in a DBA's best interest to migrate to the built in
stuff asap. From what I've seen most of the data types are easily compatible,
the biggest problem is removing the cruft from your schema dumps for doing
the upgrade. Not that much different than going from 8.1 -> 8.2, which I have
blogged about previously. HTH.

--
Robert Treat
Database Architect
http://www.omniti.com

Chris Travers wrote:
> Hi all;
>
> I know -hackers is the preferred place to discuss beta releases, but I
> suspect that this is a further-reaching wuestion among the general
> community than is typical so I am posting it here.
>
> I have been looking at the changes expected for 8.3 and have noticed
> that tsearch2 has been modified and merged with core. I think this is a
> great idea, but it poses problems for applications which must run both
> both on 8.2 and 8.3 with fts capabilities.
>
> I am trying to determine the best way forward so that LedgerSMB can
> support 8.3 as soon as it is released. Reading through various email
> list archives it looks like the function names have changed. I guess I
> am trying to determine the best way forward.
>
> 1) How safe is it likely to be to create a set of functions in 8.3
> which mimic 8.2/tsearch2 interfaces? Is this likely to create any
> serious conflicts? Would such a project be sufficiently useful that a
> pg_foundry project might be helpful?
>
> 2) If this is a problem, is the community interested in (possibly as a
> pg-foundry project) an abstraction layer for supporting both sets of
> interfaces?
>
> Best Wishes,
> Chris Travers

I don't really have answers... but more questions:

How many fts functions do you use? I had two different functions
(to_query and rank I think).

Are you thinking of always using the abstraction layer, or at some
point, dropping it and converting to the new names?

How hard would it be to test for the existence of the function and use
the one you find? (test for the old fts function name and use that if
it exists, else use the new fts function name) Ahh, shoot, that would
assume the arguments are exactly the same though... (they might be,
guess it depends on which functions you're using).

-Andy