Re: tsearch2 in PostgreSQL 8.3? - Mailing list pgsql-hackers

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