t8y2/dbx · error

custom type %s.%s does not exist

Error message

custom type %s.%s does not exist

What it means

getTypeDetails() in the Vastbase/PostgreSQL metadata driver queried sys_catalog/pg_catalog for a custom type and the query returned zero rows, meaning no type with that schema-qualified name exists in the database. The library treats a missing catalog row as a hard error because it cannot describe a type that is not in the catalog. It is raised only after the query itself succeeded (rows.Err() was nil), so it is a genuine 'not found', not an I/O failure.

Source

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

		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 {
		return nil, err
	}
	if !typisdefined {
		return nil, fmt.Errorf("custom type %s.%s is not fully defined", schema, name)
	}
	if typelem != 0 {
		return nil, fmt.Errorf("custom type %s.%s is an array companion type", schema, name)

View on GitHub (pinned to c0390bff16)

Solutions

  1. Verify the type exists with an explicit catalog query: SELECT n.nspname, t.typname FROM pg_type t JOIN pg_namespace n ON n.oid=t.typnamespace WHERE t.typname='<name>';
  2. Correct the schema and type name strings passed to getTypeDetails, matching exact case and quoting as created
  3. Confirm you are connected to the intended database/host and that the type was created (check migration logs)
  4. If the type may legitimately be absent, check existence first (or catch this error) instead of treating it as fatal

Example fix

// before
details, err := srv.getTypeDetails("public", "MyStatus") // "MyStatus" was created as "mystatus"
// after
details, err := srv.getTypeDetails("public", "mystatus")
Defensive patterns

Strategy: validation

Validate before calling

func typeExists(ctx context.Context, q Queryer, schema, name string) (bool, error) {
    var n int
    err := q.QueryRowContext(ctx,
        "SELECT count(*) FROM pg_catalog.pg_type t JOIN pg_catalog.pg_namespace n ON n.oid=t.typnamespace WHERE n.nspname=$1 AND t.typname=$2",
        schema, name).Scan(&n)
    return n > 0, err
}

Try / catch

details, err := srv.getTypeDetails(schema, name)
if err != nil {
    if strings.Contains(err.Error(), "does not exist") {
        return nil, nil
    }
    return nil, err
}

Prevention

When it happens

Trigger: Calling getTypeDetails (or the driver API that surfaces type metadata) with a schema.name that does not match any row in pg_type/sys_catalog.typ; a typo in the type or schema name; querying an unquoted mixed-case name that was created quoted; querying the wrong database or the wrong server connection; the type was dropped by a concurrent migration before the lookup.

Common situations: Migration scripts dropped or renamed the type between planning and execution; connecting to a different environment (staging vs prod) where the type was never created; search_path confusion causing the caller to pass the wrong schema; spelling the type without the schema it actually lives in; running against a Vastbase instance in MySQL compatibility mode or an older version lacking the type.

Related errors

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