From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoid recasting text to tsvector when calculating selectivity |
Date: | 2008-07-17 05:26:52 |
Message-ID: | 14053.1216272412@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-17 05:35:05 | Re: [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils. |
Previous Message | Abbas | 2008-07-17 03:36:39 | temp table problem |