"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org