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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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.
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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token \n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token \n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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.
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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token \n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token \n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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.
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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token \n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token \n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token \n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token \n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token \n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token \n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\nText 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 \u2014 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.
\nThe built-in parser is named pg_catalog.default. It recognizes 23 token types, shown in Table\u00a012.1.
Table\u00a012.1.\u00a0Default Parser's Token Types
\n| Alias | \nDescription | \nExample | \n
|---|---|---|
asciiword | \nWord, all ASCII letters | \nelephant | \n
word | \nWord, all letters | \nma\u00f1ana | \n
numword | \nWord, letters and digits | \nbeta1 | \n
asciihword | \nHyphenated word, all ASCII | \nup-to-date | \n
hword | \nHyphenated word, all letters | \nl\u00f3gico-matem\u00e1tica | \n
numhword | \nHyphenated word, letters and digits | \npostgresql-beta1 | \n
hword_asciipart | \nHyphenated word part, all ASCII | \npostgresql in the context postgresql-beta1 | \n
hword_part | \nHyphenated word part, all letters | \nl\u00f3gico or matem\u00e1tica in the context l\u00f3gico-matem\u00e1tica | \n
hword_numpart | \nHyphenated word part, letters and digits | \nbeta1 in the context postgresql-beta1 | \n
email | \nEmail address | \nfoo@example.com | \n
protocol | \nProtocol head | \nhttp:// | \n
url | \nURL | \nexample.com/stuff/index.html | \n
host | \nHost | \nexample.com | \n
url_path | \nURL path | \n/stuff/index.html, in the context of a URL | \n
file | \nFile or path name | \n/usr/local/foo.txt, if not within a URL | \n
sfloat | \nScientific notation | \n-1.234e56 | \n
float | \nDecimal notation | \n-1.234 | \n
int | \nSigned integer | \n-1234 | \n
uint | \nUnsigned integer | \n1234 | \n
version | \nVersion number | \n8.3.0 | \n
tag | \nXML tag | \n<a href=\"dictionaries.html\"> | \n
entity | \nXML entity | \n& | \n
blank | \nSpace symbols | \n(any whitespace or punctuation not otherwise recognized) | \n
The parser's notion of a \u201cletter\u201d 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 ending with -->, and XML declarations (but note that this includes anything starting with <?x 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:
\nSELECT alias, description, token FROM ts_debug('foo-bar-beta1');\n alias | description | token\n-----------------+------------------------------------------+---------------\n numhword | Hyphenated word, letters and digits | foo-bar-beta1\n hword_asciipart | Hyphenated word part, all ASCII | foo\n blank | Space symbols | -\n hword_asciipart | Hyphenated word part, all ASCII | bar\n blank | Space symbols | -\n hword_numpart | Hyphenated word part, letters and digits | beta1\n\nThis behavior is desirable since it allows searches to work for both the whole compound word and for components. Here is another instructive example:
\nSELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');\n alias | description | token\n----------+---------------+------------------------------\n protocol | Protocol head | http://\n url | URL | example.com/stuff/index.html\n host | Host | example.com\n url_path | URL path | /stuff/index.html\n\n