Re: tsearch2 in PostgreSQL 8.3?

Luke Lonergan wrote:
> All - we have customers who very much want tsearch2 and will benefit from its inclusion in core.
>
> We are also struggling with the update trigger approach for various reasons.
>
> Is there a good alternative? Can we embed tsvector updates into the core code efficiently?

No, doing it automatically adds too much complexity for little benefit.
If you want more concrete suggestions, you will have to provide more
information about the problems you are having.

---------------------------------------------------------------------------

>
> - Luke
>
> Msg is shrt cuz m on ma treo
>
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Friday, August 17, 2007 11:28 AM Eastern Standard Time
> To: Oleg Bartunov
> Cc: Josh Berkus; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] tsearch2 in PostgreSQL 8.3?
>
> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > On Thu, 16 Aug 2007, Josh Berkus wrote:
> >> First off, I'll assert that backup/restore is a serious issue and while the
> >> folks who want Tsearch in core now are dismissing it, we'll be fielding the
> >> complaints later. Any solution which involves setting a GUC at restore time
> >> *which could vary per table or even column* isn't acceptable.
>
> > Josh, all my respects to you, but text searching is not about index at all.
> > Text searching is about tsvector and tsquery data type
>
> What's your point? The problem is just as bad for an auto-update
> trigger that computes a stored tsvector column. If the trigger's
> behavior depends on the GUC settings of the person doing an insert,
> things will soon be a mess --- do you really want the tsvector contents
> to change after an update of an unrelated field? After awhile you
> won't have any idea what's really in the column, because you won't
> have any good way to know which rows' tsvectors were generated with
> which configurations.
>
> Even if that state of affairs is really what you want, reproducing
> it after a dump/reload will be tricky. I think that a regular
> schema-and-data dump would work, because pg_dump doesn't install
> triggers until after it's loaded the data ... but a data-only dump
> would *not* work, because the trigger would fire while loading rows.
>
> Basically I see no use for a setup in which the configuration used
> for a particular tsvector value is not fully determined by the table
> definition. Whether the value is in an index or in the table proper
> is irrelevant to this argument.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +