Hi there,
sorry, if I will a bit verbose - just tried to answer to several postings.
On Wed, 24 Jan 2007, Tom Lane wrote:
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.
I see your argument, no problem with that. We intentionally announced
its availability several weeks ago.
Peter Eisentraut <[EMAIL PROTECTED]> 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?
this is a real question and we will prepare UPGRADE notes.
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.
If you're talking about SQL and psql commands, than they are new and we tried
to be consistent with existing approach to manage system objects.
Any inconsistence we'd be happy to discuss and improve.
I don't remember we changed operators and function for a long
time, so users of tsearch2 should not be confused.
After all, our intention is to meet user's wish to have FTS in PostgreSQL and
nothing more. We several times wrote in mailing list that it's too early
to move tsearch2 to the pg core, since we consider (that time) it has some
scalability problem. GiN was specially developed to solve this problem and
it did it.
It's de facto standard to have FTS in modern database and
it has no difference how you call it - plugin, extension, contrib module or
built-in.
It's infair to compare approach of commercial DB with postgres, since
they have their own marketing police - they charge separately for every
extension ! Our usual peer - MySQL has built-in FTS, for example, and
I don't see any objections to not have an additional argument for our
PR people, since our FTS is a way better.
I agree, that requirements for core features should be stronger
that for contrib module, especially, for the stability of API. So, let us
discuss it. We are open for suggestions for about 6 years :)
I
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
