Re: ts_rewrite aggregate API seems mighty ugly

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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