Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
By the argument that it's better to break things obviously than to
break them subtly, risking case 4 seems more attractive than risking
case 2.
The single thought is: usually, it's very hard to see that query returns more
results that it should be. It doesn't matter for fulltext search (and it has
very good chance to stay unnoticed forever because wrong rows will be sorted
down by ranking function, although performance will decrease.
Hmm ... that's a good point. And the performance loss that I'm
complaining about is probably not large, unless you've got a *really*
expensive operator. Maybe we should leave it as-is.
Anybody else have an opinion?
Better slow than wrong in this case.
The "better to break obviously than subtly" argument doesn't hold here,
because "slow" isn't the same as broken, and returning extra incorrect
rows isn't "obviously" :-).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
