Jan Urbański wrote:
I've been fooling around my GSoC project, and here's the first version I'm not actually ashamed of showing.
Oh, wow, at this speed you'll be done before the summer even starts ;-)
There's one fundamental problem I came across while writing a typanalyze function for tsvectors. update_attstats() constructs an array that's later inserted into the appropriate stavaluesN for a given relation attribute. However, it assumes that the elements of that array will be of the same type as their corresponding attribute.
Yep, those stavalues fields are quite a hack...
It is no longer true with the design that I planned to use. The typanalyze function for the tsvector type returns an array of most-frequent lexemes (cstrings actually) from the tsvectors, not an array of tsvectors. The question is: is this approach OK? Should typanalyze functions be able to communicate the type of their result to analyze_rel() ? I'm thinking of extending the VacAttrStats structure, so a typanalyze func could set the proper fields to the proper values.re
Hmm. One idea is to store an array of tsvectors, with only one lexeme in each tsvector.
-- 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
