Re: ts_rewrite aggregate API seems mighty ugly - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ts_rewrite aggregate API seems mighty ugly
Date
Msg-id 12102.1193152239@sss.pgh.pa.us
Whole thread Raw
In response to Re: ts_rewrite aggregate API seems mighty ugly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> True.  I'll bet you don't like ts_stat() either.

>> It seems the right way interface here wouldn't be too different from what's
>> there. ...

> I'm not sure that's so much cleaner than what's there.

It doesn't seem like anyone else is particularly excited about this.
What I'm inclined to do is
* remove the aggregate form of ts_rewrite, which seems unusably  broken because of the problem with the no-rewrites
case.*leave the text-query-input form alone.* leave ts_stat alone.
 

Perhaps future improvements to the aggregate-function mechanisms will
allow these forms of ts_rewrite and ts_stat to be deprecated in favor of
aggregate-based ones.  But for now they offer useful functionality, and
no one else seems to like the idea of hiding them in a contrib module.

One small thing that I am inclined to do, though, is tweak the SPI calls
inside these functions to pass read_only = true.  This is not so much to
prevent someone from doing a non-SELECT query, as to cause the invoked
query to use the same snapshot as the outer query is using.  That'll
possibly avoid some odd behaviors, especially in scenarios where the
function gets evaluated more than once in the outer query.  As the
code stands you could conceivably get different answers.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: Latin vs non-Latin words in text search parsing
Next
From: Tom Lane
Date:
Subject: Re: Latin vs non-Latin words in text search parsing