README references missing pg_textsearch installer script

[Sanderhoff-alt]

Hi pg0 maintainers,

The README currently documents installing pg_textsearch with:

curl -fsSL https://raw.githubusercontent.com/vectorize-io/pg0/main/extensions/install-pgtextsearch.sh | bash

and:

curl -fsSL https://raw.githubusercontent.com/vectorize-io/pg0/main/extensions/install-pgtextsearch.sh | bash -s -- --version v0.5.1 --instance myapp

However, that URL currently returns 404:

https://raw.githubusercontent.com/vectorize-io/pg0/main/extensions/install-pgtextsearch.sh
HTTP/2 404

I also could not find an extensions/ directory or an install-pgtextsearch.sh script in the repository tree. From a local clone, searching the visible history and tags did not show the script either:

git log --all --full-history --name-status -- extensions/install-pgtextsearch.sh
git log --all --name-only --pretty=format: | sort -u | rg -i 'pg[_-]?text|textsearch|extension|install'

The README section appears to have been introduced in commit 93a19d18 (docs: add changelog to README), but that commit only modified README.md and did not add the installer script.

Expected behavior

Either:

1. Commit/provide the documented extensions/install-pgtextsearch.sh script, or
2. Update the README to remove or correct the pg_textsearch installation instructions, or
3. Clarify that pg_textsearch support is planned but not currently implemented.

Preferred support model

If pg_textsearch support is intended to be official, bundling or using pg0-tested prebuilt artifacts would likely fit the project better than a best-effort script that builds or downloads from upstream at install time.

The current pg0 build already works this way for core bundled components:

• PostgreSQL is downloaded as a prebuilt bundle during build.rs.
• pgvector is downloaded from a prebuilt pgvector_compiled release during build.rs.
• Those bytes are embedded into the pg0 binary and extracted into the pg0 installation at runtime.

So for optional full-text extensions such as pg_textsearch, a robust support model could be:

1. Prefer bundled, pg0-tested extension artifacts where feasible.
2. If default bundling is too large, provide an on-demand installer that downloads pinned artifacts known to match pg0's bundled PostgreSQL version and platform.
3. Avoid pulling arbitrary upstream latest artifacts, since PostgreSQL extensions are sensitive to Postgres major version, platform, ABI, install paths, and runtime dependencies.

That would make the documented support more consistent with pg0's zero-config/predictable-binary model.

Why this matters

The README currently gives the impression that pg0 supports installing pg_textsearch through an official one-command installer, but the documented command fails. This makes it unclear whether pg_textsearch is actually supported today or only planned.

Thanks.

[Sanderhoff-alt]

One possible direction, if maintaining multiple optional BM25 extension paths is not desirable, would be to drop the documented pg_textsearch installer path and focus official support on pg_search instead.

The reason is not that pg_textsearch is inherently unhelpful, but that pg_search may be a better fit for the kind of modern hybrid-search workloads pg0 is already well positioned for:

• It pairs naturally with pgvector for dense + sparse retrieval.
• It has a configurable tokenizer story that is useful for multilingual and CJK workloads.
• It provides parity for applications already targeting the ParadeDB pg_search API.
• It may be more compelling as the single optional/full bundled BM25 backend if pg0 wants to avoid supporting multiple extension build matrices.

So another acceptable resolution for this issue could be: remove or mark the current pg_textsearch installer docs as unsupported/planned, and concentrate extension packaging work on pg_search instead. That would avoid documenting a broken installer while giving pg0 a clearer long-term full-text search direction.