12.5. Parsers
Text search parsers are responsible for splitting raw document text into tokens and identifying each token's type, where the set of possible types is defined by the parser itself. Note that a parser does not modify the text at all - it simply identifies plausible word boundaries. Because of this limited scope, there is less need for application-specific custom parsers than there is for custom dictionaries. At present PostgreSQL provides just one built-in parser, which has been found to be useful for a wide range of applications.
  The built-in parser is named
  
   pg_catalog.default
  
  .
   It recognizes 23 token types, shown in
  
   Table 12.1
  
  .
 
Table 12.1. Default Parser's Token Types
Note
   The parser's notion of a
   
    "
    
     letter
    
    "
   
   is determined by the database's
    locale setting, specifically
   
    lc_ctype
   
   .  Words containing
    only the basic ASCII letters are reported as a separate token type,
    since it is sometimes useful to distinguish them.  In most European
    languages, token types
   
    word
   
   and
   
    asciiword
   
   should be treated alike.
  
   
    email
   
   does not support all valid email characters as
    defined by
   
    RFC 5322
   
   .
    Specifically, the only non-alphanumeric characters supported for
    email user names are period, dash, and underscore.
  
   
    tag
   
   does not support all valid tag names as defined by
   
    W3C Recommendation, XML
   
   .
    Specifically, the only tag names supported are those starting with an
    ASCII letter, underscore, or colon, and containing only letters, digits,
    hyphens, underscores, periods, and colons.
   
    tag
   
   also
    includes XML comments starting with
   
    
   
   , and XML declarations (but note that this
    includes anything starting with
   
    
   and ending with
   
    >
   
   ).
  
It is possible for the parser to produce overlapping tokens from the same piece of text. As an example, a hyphenated word will be reported both as the entire word and as each component:
SELECT alias, description, token FROM ts_debug('foo-bar-beta1');
      alias      |               description                |     token
-----------------+------------------------------------------+---------------
 numhword        | Hyphenated word, letters and digits      | foo-bar-beta1
 hword_asciipart | Hyphenated word part, all ASCII          | foo
 blank           | Space symbols                            | -
 hword_asciipart | Hyphenated word part, all ASCII          | bar
 blank           | Space symbols                            | -
 hword_numpart   | Hyphenated word part, letters and digits | beta1
 This behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
SELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');
  alias   |  description  |            token
----------+---------------+------------------------------
 protocol | Protocol head | http://
 url      | URL           | example.com/stuff/index.html
 host     | Host          | example.com
 url_path | URL path      | /stuff/index.html