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