Problem
The authenticate function (auth.go:17-90) performs the PostgreSQL password
handshake - receives the StartupMessage, requests the cleartext password, and
returns the extracted credentials (provider, API key, model, options). It does
no validation.
Separately, sendStartupMessages (auth.go:93-139) sends AuthenticationOk and
startup parameters to the client - also with no validation.
Between these two calls and the query loop, nothing verifies that the API key
is valid or the model exists. The user only finds out on their first query
when the LLM API call fails.
Proposed solution
Add a Validate(ctx) error method to the LLMClient interface. Call it in
connection.go after creating the LLM client (line ~113) and before entering
the query loop (line ~117).
Each provider implements validation differently:
- OpenAI:
GET /v1/models or a minimal completion call
- Anthropic: minimal message call or equivalent
On failure, send a PostgreSQL FATAL error and close the connection:
- Invalid API key →
FATAL 28P01 (invalid_password)
- Invalid/unavailable model →
FATAL 3D000 (invalid_catalog_name)
Considerations
- Adds latency to every new connection - should use the cheapest possible API call
- Could be opt-out via a flag (
-skip-validation) for local/trusted setups
Problem
The
authenticatefunction (auth.go:17-90) performs the PostgreSQL passwordhandshake - receives the StartupMessage, requests the cleartext password, and
returns the extracted credentials (provider, API key, model, options). It does
no validation.
Separately,
sendStartupMessages(auth.go:93-139) sends AuthenticationOk andstartup parameters to the client - also with no validation.
Between these two calls and the query loop, nothing verifies that the API key
is valid or the model exists. The user only finds out on their first query
when the LLM API call fails.
Proposed solution
Add a
Validate(ctx) errormethod to theLLMClientinterface. Call it inconnection.go after creating the LLM client (line ~113) and before entering
the query loop (line ~117).
Each provider implements validation differently:
GET /v1/modelsor a minimal completion callOn failure, send a PostgreSQL FATAL error and close the connection:
FATAL 28P01 (invalid_password)FATAL 3D000 (invalid_catalog_name)Considerations
-skip-validation) for local/trusted setups