CREATE_TEXT_SEARCH_PARSER(7pg18)

💖 CREATE TEXT SEARCH PARSER(7) 💖

okay bestie, welcome to the manual page for CREATE TEXT SEARCH PARSER — yes that's the whole name, and yes it's a section 7 page, so grab a strawberry drink and let's go 🍓

---

✨ NAME ✨

CREATE_TEXT_SEARCH_PARSER — define a new text search parser 💅

---

🌸 SYNOPSIS 🌸

CREATE TEXT SEARCH PARSER name (
    START = start_function ,
    GETTOKEN = gettoken_function ,
    END = end_function ,
    LEXTYPES = lextypes_function
    [, HEADLINE = headline_function ]
)

---

🦋 DESCRIPTION 🦋

okay so CREATE TEXT SEARCH PARSER does exactly what it says on the tin: it creates a brand new text search parser. and what even is a text search parser, you ask? it's the thing that defines a method for splitting a text string into tokens and assigning types (aka categories) to those tokens. slay. that's the whole job.

but here's the tea: a parser is not particularly useful by itself. it has to be bound into a text search configuration along with some text search dictionaries before it can actually be used for searching. it's giving backup dancer energy, not main character. 💀

if you give a schema name, then the text search parser gets created in that specified schema. otherwise it's created in the current schema. easy.

🚨 superuser check, no exceptions: you must be a superuser to use CREATE TEXT SEARCH PARSER. and the reason is lowkey valid — a bad text search parser definition could confuse or even crash the server. so yeah, gatekeeping, but make it safety. 😭

if you want more lore, go read Chapter 12 for further information. 📖

---

🎀 PARAMETERS 🎀

• name — the name of the text search parser you're creating. it can be schema-qualified, so go off with that dot notation. ✨
• start_function — the name of the start function for the parser. it starts things. iconic behavior. 💖
• gettoken_function — the name of the get-next-token function for the parser. it gets the next token. obsessed with the consistency here.
• end_function — the name of the end function for the parser. it ends things. closure, we love to see it. 🫶
• lextypes_function — the name of the lextypes function for the parser. this one's a function that returns information about the set of token types it produces. very "here's my whole personality in a return value" of it. 🌈
• headline_function — the name of the headline function for the parser. this is a function that summarizes a set of tokens. optional queen. 👑

a few things you need to know about these function names, bestie:

• they can be schema-qualified if necessary. 💅
• argument types are not given, because the argument list for each type of function is predetermined. it's already decided, don't come for it. 🧚
• all of them except the headline function are required. so headline_function is the only one you can skip. the rest? mandatory. periodt.
• and the arguments can appear in any order, not only the one shown above. so if you wanna be chaotic with your formatting, the parser literally doesn't care. 🦋

---

💀 COMPATIBILITY 💀

ngl there is no CREATE TEXT SEARCH PARSER statement in the SQL standard. it's just not a thing there. we're built different. 😌

---

🌟 SEE ALSO 🌟

• ALTER TEXT SEARCH PARSER (ALTER_TEXT_SEARCH_PARSER(7)) 💜
• DROP TEXT SEARCH PARSER (DROP_TEXT_SEARCH_PARSER(7)) 💜

---

and that's the page, bestie!! this whole thing is brought to you by PostgreSQL 18.6, dated 2026 ✨ go forth and tokenize responsibly, mwah 💋🎀