Re: tsearch in core patch, for inclusion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: tsearch in core patch, for inclusion
Date: 2007-01-24 18:49:23
Message-ID: 3813.1169664563@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> Teodor Sigaev wrote:
>> If there aren't objections then we plan commit patch tomorrow or
>> after tomorrow.

This is a fairly large patch and I would like the chance to review it
before it goes in --- "we'll commit tomorrow" is not exactly a decent
review window.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I still haven't heard any argument for why this would be necessary or
> desirable at all, other than that it looks better for marketing
> reasons,

One possible argument for this over the contrib version is a saner
approach to dumping and restoring configurations. However, as against
that:

1) what's the upgrade path for getting an existing tsearch2
configuration into this implementation?

2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion. It was OK
for tsearch2's API to change every release while it was in contrib, but
the expectation of stability is a whole lot higher for core features.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-24 18:53:38 Re: weird buildfarm failures on arm/mipsel and --with-tcl
Previous Message Joshua D. Drake 2007-01-24 18:47:18 Re: tsearch in core patch, for inclusion

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2007-01-24 18:53:54 Re: tsearch in core patch, for inclusion
Previous Message Joshua D. Drake 2007-01-24 18:47:18 Re: tsearch in core patch, for inclusion