Full-text search fails: `to_tsvector` and `to_tsquery` are not found, and `@@` is not yet supported

On DoltgreSQL 1.3.1, full-text search fails at its first step: `to_tsvector` is not found, and neither is
`to_tsquery`. The `@@` match operator is refused as well, whatever its operands, so a match between two
plain text values fails too:

```
psql:/tmp/repro.sql:2: ERROR: function: 'to_tsvector' not found
psql:/tmp/repro.sql:5: ERROR: function: 'to_tsquery' not found
psql:/tmp/repro.sql:9: ERROR: @@ is not yet supported
psql:/tmp/repro.sql:12: ERROR: @@ is not yet supported
```

PostgreSQL 18.6 answers `'cat':2 'fat':1` and `'cat'`, and `t` for both matches.

## Reproduction

[`repro.sql`](https://github.com/Reliable-Collaboration/repro-doltgresql-bug-text-search-operator/blob/main/repro.sql):

```sql
-- A document as a tsvector.
SELECT to_tsvector('english', 'fat cats');

-- A query as a tsquery.
SELECT to_tsquery('english', 'cat');

-- The two matched with the @@ operator.
SELECT to_tsvector('english', 'fat cats')
@@ to_tsquery('english', 'cat');

-- The @@ operator between two text values.
SELECT 'fat cats' @@ 'cat';
```

## Expected behavior

The document becomes a `tsvector`, the query a `tsquery`, and both matches answer `t`. This is what
PostgreSQL 18.6 does:

```
-- A document as a tsvector.
SELECT to_tsvector('english', 'fat cats');
to_tsvector
-----------------
'cat':2 'fat':1
(1 row)

-- A query as a tsquery.
SELECT to_tsquery('english', 'cat');
to_tsquery
------------
'cat'
(1 row)

-- The two matched with the @@ operator.
SELECT to_tsvector('english', 'fat cats')
@@ to_tsquery('english', 'cat');
?column?
----------
t
(1 row)

-- The @@ operator between two text values.
SELECT 'fat cats' @@ 'cat';
?column?
----------
t
(1 row)
```

## Actual behavior

Each of the four statements answers an error. This is what DoltgreSQL 1.3.1 does:

```
-- A document as a tsvector.
SELECT to_tsvector('english', 'fat cats');
psql:/tmp/repro.sql:2: ERROR: function: 'to_tsvector' not found
-- A query as a tsquery.
SELECT to_tsquery('english', 'cat');
psql:/tmp/repro.sql:5: ERROR: function: 'to_tsquery' not found
-- The two matched with the @@ operator.
SELECT to_tsvector('english', 'fat cats')
@@ to_tsquery('english', 'cat');
psql:/tmp/repro.sql:9: ERROR: @@ is not yet supported
-- The @@ operator between two text values.
SELECT 'fat cats' @@ 'cat';
psql:/tmp/repro.sql:12: ERROR: @@ is not yet supported
```

## Run it

A runnable reproduction is at https://github.com/Reliable-Collaboration/repro-doltgresql-bug-text-search-operator. Its script runs the test on PostgreSQL and DoltgreSQL in throwaway containers and prints the two outputs side by side:

```sh
git clone https://github.com/Reliable-Collaboration/repro-doltgresql-bug-text-search-operator.git
cd repro-doltgresql-bug-text-search-operator
./repro.sh
```

## Other observations

Each was run on the same two images with the `psql` client inside each container:

- The types are missing too: `SELECT 'fat cats'::tsvector` answers ``unable to resolve type `tsvector` ``,
`SELECT 'cat'::tsquery` answers ``unable to resolve type `tsquery` ``, and
`CREATE TABLE tv (id int, v tsvector)` answers `type "tsvector" does not exist`. PostgreSQL answers
`'cats' 'fat'` and `'cat'`, and creates the table.
- The schema-qualified type name is accepted, but as the type `unknown`:
`pg_typeof('fat cats'::pg_catalog.tsvector)` answers `unknown`, where PostgreSQL answers `tsvector`;
`SELECT 'fat cats'::pg_catalog.tsvector` answers `fat cats`, where PostgreSQL answers `'cats' 'fat'`; and
`CREATE TABLE tv2 (v pg_catalog.tsvector)` succeeds. The qualified function,
`pg_catalog.to_tsvector('english', 'fat cats')`, answers `function: 'to_tsvector' not found`.
- The forms without a configuration, `to_tsvector('fat cats')` and `to_tsquery('cat')`, are not found
either, and neither are `plainto_tsquery('english', 'cat')` and
`ts_rank(to_tsvector('fat cats'), to_tsquery('cat'))`.
- `@@` is refused whatever its operands: `SELECT 1 @@ 2` answers `@@ is not yet supported`, where
PostgreSQL answers `operator does not exist: integer @@ integer`, and so does the JSON path match
`SELECT '{"a": 1}'::jsonb @@ '$.a == 1'`, which PostgreSQL answers with `t`.
- `@@` is refused before the table is looked up: `SELECT id FROM no_such_table WHERE body @@ 'cat'`
answers `@@ is not yet supported`, where PostgreSQL answers `relation "no_such_table" does not exist`.
- Over a table with a `text` column, `WHERE body @@ 'cat'` and
`WHERE to_tsvector('english', body) @@ to_tsquery('english', 'cat')` answer `@@ is not yet supported`;
PostgreSQL answers the row whose `body` is `fat cats`.
- The setting exists: `SHOW default_text_search_config` answers `pg_catalog.english` on both engines,
though DoltgreSQL names the column `@@session.default_text_search_config`. DoltgreSQL's `pg_ts_config`
holds one configuration, `simple`; PostgreSQL's holds 30.
- `SELECT 'english'::regconfig` answers ``unable to resolve type `regconfig` ``; PostgreSQL answers
`english`.
- Upstream, issue [#759](https://github.com/dolthub/doltgresql/issues/759), "`TSVECTOR` support", was
closed in favor of [#1212](https://github.com/dolthub/doltgresql/issues/1212), "Vector support", which
asks for pgvector; pull request [#1530](https://github.com/dolthub/doltgresql/pull/1530), "support `@@`
text search operator", was closed without being merged.

## Possibly related

#759 (closed) asked for `TSVECTOR` support and was closed in favor of #1212, which is about vector search rather than text search. Pull request #1530, adding `@@`, was closed without being merged.

## Environment

- DoltgreSQL 1.3.1, the newest release when this was written: image `dolthub/doltgresql:1.3.1`, digest
`sha256:6c85cb1f35beabf47f094336a420255130b841b1645f36d79ef046276af36851`. Its bundled `psql` is 17.11.
- PostgreSQL 18.6: image `postgres:18.6-bookworm`, digest
`sha256:1c59e2c3c818eaa0f0628f695b36e7c9e362d6b219b36a54a32df645cbd7e1af`. Its `psql` is 18.6.
- Reproduced on 2026-09-11 (UTC) with Docker 29.7.2 on Linux x86_64 (WSL 2).

Start by running repro.sql through repro.sh to confirm the PostgreSQL and DoltgreSQL differences. Trace the existing handling for tsvector, tsquery, text-search functions, and the @@ operator; done means the documented functions, types, and operator cases produce the expected results without breaking invalid-operand errors.

Written by the indexing model from the issue text.