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
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 |
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 |