Re: ts_rewrite aggregate API seems mighty ugly

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Since we're already committed to an initdb for beta2, it's not quite too
> late to reconsider the API here. My feeling at the moment is that we
> should just drop the aggregate form of ts_rewrite; it does nothing you
> can't do better with the two-argument form, and it is just ugly to boot.
> Also, if anyone does come up with a not-so-ugly design later, we can
> always add things in 8.4 or beyond; but once it's in core it's going
> to be a very hard sell to take it out.

The two-argument form may not be actively broken but it sounds not very
integrated. Passing a string which is then planned as an SQL query is not very
SQL-ish. If you prepare the query does that string get prepared? When do you
get syntax errors? If the plan's invalidated does it handle it correctly?

It sounds to me like once we have a good aggregate interface there's not much
point to the two-argument form. A good aggregate form would let you do the
subquery or a join or any other form of query to fetch all the replacements
you want.

I would suggest putting both the two-argument form and the aggregate form into
a contrib module -- effectively *back* into a contrib module until the
interfaces can be fully integrated into SQL. So whereas previously you
installed a contrib module for the whole tsearch2, now it's all integrated
except for a few oddball functions which you can still get by supplementing
the core tsearch with the contrib module.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com