Re: avoid recasting text to tsvector when calculating selectivity
От | Tom Lane |
---|---|
Тема | Re: avoid recasting text to tsvector when calculating selectivity |
Дата | |
Msg-id | 14053.1216272412@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | avoid recasting text to tsvector when calculating selectivity (Jan Urbański <j.urbanski@students.mimuw.edu.pl>) |
Ответы |
Re: avoid recasting text to tsvector when calculating selectivity
|
Список | 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 по дате отправления: