Re: ts_rewrite aggregate API seems mighty ugly

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ts_rewrite aggregate API seems mighty ugly
Дата
Msg-id 12102.1193152239@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ts_rewrite aggregate API seems mighty ugly  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Glaesemann
Дата:
Сообщение: Re: Latin vs non-Latin words in text search parsing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Latin vs non-Latin words in text search parsing