Re: avoid recasting text to tsvector when calculating selectivity - Mailing list pgsql-hackers

From Tom Lane
Subject Re: avoid recasting text to tsvector when calculating selectivity
Date
Msg-id 14053.1216272412@sss.pgh.pa.us
Whole thread Raw
In response to avoid recasting text to tsvector when calculating selectivity  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
Responses Re: avoid recasting text to tsvector when calculating selectivity  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
List pgsql-hackers
Jan Urbański <j.urbanski@students.mimuw.edu.pl> writes:
> I'm about to write a oprrest function for the @@ operator. Currently @@ 
> handles multiple cases, like tsvector @@ tsquery, text @@ tsquery, 
> tsquery @@ tsvector etc. The text @@ text case is for instance handled 
> by calling to_tsvector and plainto_tsquery on the input arguments.

> For a @@ restriction function, I need to have a tsquery and a tsvector, 
> so in the text @@ text situation I'd end up calling plainto_tsquery 
> during planning, which would consequently get called again during 
> execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at 
> the beginning of the function. Is this OK/unavoidable/easly avoided?

I'm not following your point here.  Sure, there are multiple flavors of
@@, but why shouldn't they each have their own oprrest function?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Sushant Sinha
Date:
Subject: small bug in hlCover
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.