Jan Urbański wrote:
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]>
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?
Because they'll all boil down to the same function. Suppose I have an
oprrest function for tsvector @@ tsquery. An oprrest for text @@ text
would just be:
tv = DatumGetTSVector(DirectFunctionCall1(to_tsvector,
PG_GETARG_DATUM(0)));
tq = DatumGetTSQuery(DirectFunctionCall1(plainto_tsquery,
PG_GETARG_DATUM(1)));
res = DirectFunctionCall2(my_oprrest, TSVectorGetDatum(tv),
TSQueryGetDatun(tq))
...
I thought I might avoid having to call ts_tsvector and plainto_tsquery,
because the arguments need to be transformed to tsvector and tsquery
anyway during execution.
[thinks...]
OTOH, you often plan a query without executing it, so this doesn't make
sense. OK, please disregard that, I'm just beginning to see the depths
of my misunderstanding of the issue ;)
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
