Thread: tsearch2 wrapper
Hello I am working on subj. There are two variants: a) simple C wrapper which can be SQL compatible .. with this wrapper we don't need any changes in dump files .. but I thinking it's impossible, because there are conflicts between functio'n names and table's names. b) simple SQL wrapper -> it need modification of dump file :(, but it can work (probably doesn't needs modify of application). I started work on variant b) http://www.pgsql.cz/index.php/Tsearch2_wrapper plpgsql procedures I'll rewrite to C later. Now I thing, so compatibility is broken, but we can simplify port to 8.3 with some small wrapper like my wrapper. Regards Pavel Stehule
On Thursday 04 October 2007 11:52, Pavel Stehule wrote: > Hello > > I am working on subj. There are two variants: > > a) simple C wrapper which can be SQL compatible .. with this wrapper > we don't need any changes in dump files .. but I thinking it's > impossible, because there are conflicts between functio'n names and > table's names. > the new built in stuff should all be in pg_catalog schema, and the old stuff in public schema, so in theory it would work... example of conflict? > b) simple SQL wrapper -> it need modification of dump file :(, but it > can work (probably doesn't needs modify of application). > > I started work on variant b) > http://www.pgsql.cz/index.php/Tsearch2_wrapper > > plpgsql procedures I'll rewrite to C later. > > Now I thing, so compatibility is broken, but we can simplify port to > 8.3 with some small wrapper like my wrapper. thank goodness I've switched to putting tsearch in it's own schema, so I can easily seperate it with pg_dump. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes: > On Thursday 04 October 2007 11:52, Pavel Stehule wrote: >> a) simple C wrapper which can be SQL compatible .. with this wrapper >> we don't need any changes in dump files .. but I thinking it's >> impossible, because there are conflicts between functio'n names and >> table's names. > the new built in stuff should all be in pg_catalog schema, and the old stuff > in public schema, so in theory it would work... example of conflict? The problem is the pg_catalog entries would capture any unqualified names. regards, tom lane