apache / apache/shardingsphere

PostgreSQL Custom Types Parsing Issue in ShardingSphere-Proxy

Open
#36,978 5 comments 0 reactions 1 assignee Claimed by @zxs1633079383 View on GitHub
db: PostgreSQL
Dominant language
Java
Stars
20.8k
Forks
6.9k
Avg merge
11h 38m
Merged PRs (30d)
326

Description

# PostgreSQL Custom Types Parsing Issue in ShardingSphere-Proxy

## Description

I am using **ShardingSphere-Proxy version 5.5.2** with PostgreSQL.
In my database, I have custom data types, for example `varbit`.

When `TableMetaData` is loaded, these columns are identified as JDBC type `1111` (i.e., `Types.OTHER`).
As a result, the system defaults to the JSON parser for these columns. This behavior makes it impossible to process custom PostgreSQL types correctly, because JSON parsing is not applicable for types like `varbit`.

This raises a general concern: how should other PostgreSQL custom business types be handled properly through ShardingSphere-Proxy?

## Observed Problem

- Custom PostgreSQL types are treated as `Types.OTHER` (1111).
- The default JSON parser is applied, which fails for types like `varbit` or other user-defined types.
- Currently, multiple types would require multiple parsers unless a unified parser can be applied.
- Even in fast sequential operations, timestamp fields generated by `time.Now().UnixMilli()` can collide because of millisecond precision.

## Questions / Suggestions

1. How can we register or configure a parser for PostgreSQL custom types in ShardingSphere-Proxy 5.5.2?
2. Is there a recommended way to map PostgreSQL `udt_name` to a parser so that multiple custom types can share a single generic parser?
3. How can PostgreSQL UDTs flow correctly through ShardingSphere-Proxy without breaking inserts or selects?

## Environment

- ShardingSphere-Proxy version: 5.5.2
- PostgreSQL
- Custom types examples: `varbit`, `bit`, other user-defined types

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.