Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It may be worth doing anyway --- certainly CREATE OPERATOR CLASS was a
>> huge improvement over the previous ways of doing it --- but don't
>> underestimate the size of what we're talking about.
> Hmm, actually the tsearch2 directory contains 16500 lines of code
> (generated using David A. Wheeler's 'SLOCCount'), so I didn't doubt that
> it's a big piece of code as a whole -- but I thought what was being
> discussed was the size of the grammar changes, which is why I mentioned
> the "a couple dozen" figure.
No, what I was on about was the cost of inventing custom-SQL-statement
manipulation of the catalog entries that drive tsearch2. The analogy to
operator classes is fairly exact, because before 7.3 you had to
manipulate those using direct insertions of catalog entries. The
manipulation commands are just about independent of the actual use of
the catalog entries --- my count of "support" didn't include any of the
planner or index AM code that actually uses operator classes, and in the
same way the existing tsearch2 code doesn't have any particular
relationship to this new code that'd have to be written to support the
manipulation commands.
> Having the supporting code in core does not make much of a difference
> otherwise from having it in contrib, does it?
Given the nonextensibility of gram.y and keywords.c, it has to be in
core to even think about having special syntax :-(
regards, tom lane
---------------------------(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
