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 по дате отправления: