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