t8y2/dbx · error

failed to locate custom type %s.%s: %w

Error message

failed to locate custom type %s.%s: %w

What it means

This wraps any error returned while executing the general catalog query that locates the custom type row in sys_catalog/pg_catalog (vastbase_metadata.go:611-613). The driver found the type lookup SQL failed — the type itself may or may not exist; the failure is at query execution time, not a 'not found' result.

Source

Thrown at agents/drivers/vastbase-go/vastbase_metadata.go:613

	}
	schema = strings.TrimSpace(schema)
	name = strings.TrimSpace(name)
	if schema == "" || name == "" {
		return nil, errors.New("schema and type name are required")
	}
	if isSystemSchema(schema) {
		return nil, fmt.Errorf("system schema %s is not supported for custom type details", schema)
	}
	catalog := "sys_catalog"
	if s.mode.postgresCatalog {
		catalog = "pg_catalog"
	}
	prefix := catalogPrefix(catalog)
	queries := customTypeCatalogQueriesFor(catalog, prefix, schema, name)

	rows, err := s.metadataQuery(queries.general)
	if err != nil {
		return nil, fmt.Errorf("failed to locate custom type %s.%s: %w", schema, name, err)
	}
	defer rows.Close()
	if !rows.Next() {
		if err := rows.Err(); err != nil {
			return nil, fmt.Errorf("failed to read type %s.%s: %w", schema, name, err)
		}
		return nil, fmt.Errorf("custom type %s.%s does not exist", schema, name)
	}
	var oid, typbasetype, typrelid, typelem, typcollation int64
	var typtype, typalign, typstorage string
	var typisdefined, typnotnull, typbyval bool
	var typdefaultbin, typdefault, inputFn, outputFn, receiveFn, sendFn, analyzeFn, comment, collname, relkind sql.NullString
	var typlen sql.NullInt64
	var typtypmod int64
	if err := rows.Scan(&oid, &typtype, &typisdefined, &typbasetype, &typnotnull, &typrelid, &typelem, &typcollation, &typdefaultbin, &typdefault, &typlen, &typbyval, &typalign, &typstorage, &typtypmod, &inputFn, &outputFn, &receiveFn, &sendFn, &analyzeFn, &comment, &relkind, &collname); err != nil {
		return nil, fmt.Errorf("failed to read type %s.%s: %w", schema, name, err)
	}
	if err := rows.Close(); err != nil {

View on GitHub (pinned to c0390bff16)

Solutions

  1. Reconnect and retry: verify the connection is alive (db.PingContext) before calling get_type_details.
  2. Grant the connecting role SELECT privileges on the relevant system catalog tables.
  3. Check the wrapped error (%w) for the root cause — version-specific SQL errors may require upgrading the driver or enabling the correct catalog mode (pg_catalog vs sys_catalog).
  4. Confirm you are connecting to a Vastbase/Postgres-compatible server matching the driver's supported versions, not an incompatible fork.

Example fix

// before
rows, err := s.metadataQuery(queries.general) // err: connection reset
// after
if err := s.db.PingContext(ctx); err != nil {
    if err := s.reconnect(); err != nil { return nil, err }
}
rows, err := s.metadataQuery(queries.general)
Defensive patterns

Strategy: try-catch

When it happens

Trigger: Calling get_type_details when the underlying metadataQuery for queries.general fails: connection dropped or closed mid-call, insufficient privileges to read catalog tables, catalog tables missing/renamed on an incompatible server version, or SQL syntax the server rejects (e.g. features like multirange columns absent in older Vastbase).

Common situations: Server connection terminated by idle timeout or network blip; read-only/limited role lacking SELECT on system catalogs; connecting the driver to a server variant whose catalog layout differs from what the queries assume.

Related errors

AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/19b92beaa060ab83. Report an issue: GitHub.