Bruce,
> It seems unfair to disinguish between early/last in cycle postings.
I think it's fair. A patch which was submitted for 8.2 and didn't get in
should get consideration over a patch which was still in prototype form a
week before feature freeze. Also, I really don't think it's a crime to push
back patches which are under active redevelopment (seqscan) if that
redevelopment isn't a result of review neglect.
> > Obviously for 8.4 reviewers need to start reviewing stuff from the first
> > week of the development cycle. I also don't actually see anything wrong
> > with a 3-month feature freeze if we can somehow branch development
> > earlier. Easy for me to say, I know.
>
> Yea, this is just pushing off work until later, which I don't support.
> There is no easy out here and I am afraid we will just have to accept a
> 3-month feature freeze.
I think that may be where we're heading. In that case, we may need to talk
about branching earlier so that developers can work on the new version who
are frozen out of the in-process one.
> Oleg has been producing new versions of his patch, and no one has
> objected to any of it, so I assume all the issues were addressed.
>
> As far was whether tsearch2 should be in core, I think most agreed that
> SQL support for full-text would make it easier to use, and that it is a
> fundamental technology. As I remember, the only holdback was full
> multi-byte support, but that is done.
I'm going to echo Bruce on this; I've mentioned that TSearch was going into
Core at conferences and the reaction from existing users has been very
enthusiastic, ranging from "yippee!" to "about time!". Our users hate the
fact that FTS is a separate module.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
