really change anything.  Per report from Itagaki Takahiro.  Fix by
Pavan Deolasee.

and ts_stat(), per my recent suggestion.  Also add a possibly-not-needed-
but-can't-hurt check for NULL SPI_tuptable, before we try to dereference
same.

if there are zero rows to aggregate over, and the API seems both conceptually
and notationally ugly anyway.  We should look for something that improves
on the tsquery-and-text-SELECT version (which is also pretty ugly but at
least it works...), but it seems that will take query infrastructure that
doesn't exist today.  (Hm, I wonder if there's anything in or near SQL2003
window functions that would help?)  Per discussion.

Needed to accommodate different layout on some platforms (Debian for
one).  Heikki Linnakangas

categories, as per discussion.  asciiword (formerly lword) is still
ASCII-letters-only, and numword (formerly word) is still the most general
mixed-alpha-and-digits case.  But word (formerly nlword) is now
any-group-of-letters-with-at-least-one-non-ASCII, rather than all-non-ASCII as
before.  This is no worse than before for parsing mixed Russian/English text,
which seems to have been the design center for the original coding; and it
should simplify matters for parsing most European languages.  In particular
it will not be necessary for any language to accept strings containing digits
as being regular "words".  The hyphenated-word categories are adjusted
similarly.

SHGetFolderPath.

This removes the direct dependency on shell32.dll and user32.dll, which
eats a lot of "desktop heap" for each backend that's started. The
desktop heap is a very limited resource, causing backends to no
longer start once it's been exhausted.

We still have indirect depdendencies on user32.dll through third party
libraries, but those can't easily be removed.

Dave Page

a later rewrite rule should change a subtree modified by an earlier one.
Per my gripe of a few days ago.

miscomputation of required palloc size.  The crash could only occur if the
input contained lexemes both with and without positions, which is probably not
common in practice.  The miscomputation would definitely result in wasted
space.  Also fix some inconsistent coding around alignment of strings and
positions in a tsvector value; these errors could also lead to crashes given
mixed with/without position data and a machine that's picky about alignment.
And be more careful about checking for overflow of string offsets.

Patch is only against HEAD --- I have not looked to see if same bugs are
in back-branch contrib/tsearch2 code.

James Shaw.  Also update a couple of examples to reflect 8.3's improved
plan-printing code.

active dictionary and its output lexemes as separate columns, instead
of smashing them into one text column, and lowercase the column names.
Also, define the output rowtype using OUT parameters instead of a
composite type, to be consistent with the other built-in functions.

ITAGAKI Takahiro

representation of DECLARE CURSOR.  Report and fix by Heikki.

Per Greg Stark & Dave Page

users of tsearch.  This isn't meant to be permanent documentation,
but to call out the areas that need either fixing or real documentation.

versions of gcc (I'm seeing it with Apple's gcc 4.0.1).  I think the
reason we did not see this before was that the assert() macros in the
regex code were all no-ops till recently.

tsvector" when we are really parsing a tsquery.  Report the bogus input,
too.  Make styles of some related error messages more consistent.

more clearly, improve a lot of unclear descriptions, add some missing
material.  We still need a migration guide though.

Jun Kuwamura

uniformly calls these things weights, not classes.

Ian Barwick

the syslog configuration file (at least not on most known Unixen).
I dunno why we hadn't had that info in the docs all along ...

are really redundant, since we invented a regdictionary alias type.
We can have just one function, declared as taking regdictionary, and
it will handle both behaviors.  Noted while working on documentation.

pg_proc.h.

8.3 consistently.

entries and removed a few.

    <H3 id="item4.19">4.19) Why do I get "relation with OID #####
    does not exist" errors when accessing temporary tables in PL/PgSQL
    functions?</H3>

Also enable translation of PG_WIN874, which certainly seems to have an
obvious translation now, though maybe it did not at the time this table's
ancestor was created.

Notably, standardize on using "token" for the strings output by a parser,
while "lexeme" is reserved for the normalized strings produced by a
dictionary.