Tom Lane wrote:
Well, there is exactly zero chance of that happening in 8.3.x, because
the bit allocations for on-disk tsvector representation are already
determined. It's fairly hard to see a way of doing it in future
releases that would have acceptable costs, either.
I think you missed my point or i didn't explain it in details. I'm
talking about doing the error-or-notice condition to be a guc variable
(eg ignore_tsearch_limits = on/off).
But more to the point: no matter what the document length limit is,
why should it be a hard error to exceed it? The downside of not
indexing words beyond the length limit is that searches won't find
documents in which the search terms occur only very far into the
document. The downside of throwing an error is that we can't store such
documents at all, which surely guarantees that searches won't find
them. How can you possibly argue that that option is better?
IMHO, both of the approaches are "bad"; that's why i propose an user
option. So the user can choose between to be strict (error out when it
exceeds some limit) and to relax (emit a notice when it exceeds some
limit). Maybe some day we can increase the limits (eg ts_type.h redesign).
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
