goutamadwant opened a new issue, #12834:
URL: https://github.com/apache/seatunnel/issues/12834
### What happened
When PostgreSQL CDC encounters a type created after `TypeRegistry` was
primed, `TypeRegistry.get(String)` queries `pg_type` by unqualified `typname`.
If two schemas contain that name, the current query has no visibility ordering
and can select a type that the source connection cannot resolve through its
`search_path`. The selected OID may therefore differ from PostgreSQL's
`to_regtype(name)` result.
This is a source-side type lookup defect. It is separate from #12601, which
concerns quoting/schema qualification when a PostgreSQL sink generates
downstream `ADD COLUMN` DDL.
### Reproduction
On a real PostgreSQL instance, create a registry before the new types are
added. Then, on the same source connection:
```sql
CREATE SCHEMA type_lookup_a;
CREATE SCHEMA type_lookup_b;
CREATE TYPE type_lookup_b.late_mood AS ENUM ('b');
CREATE TYPE type_lookup_a.late_mood AS ENUM ('a');
SET search_path TO type_lookup_a, public;
SELECT to_regtype('late_mood')::oid;
```
Compare that result with `registry.get("late_mood").getOid()`. The existing
cache-miss query filters only on `t.typname = ?`; it has no rule to prefer the
visible candidate. Reversing type-creation order and `search_path` exercises
the opposite case. The regression test also checks a name with no visible
candidate and direct OID lookup.
No full job configuration is needed to reproduce this registry path. The
issue was reproduced against the `dev` code at `c0d2398c8` with PostgreSQL
Testcontainers on Java 11.0.19; the current `dev` still has the same lookup
query.
### Expected behavior and proposed fix
For a cache miss by unqualified name, prefer the type visible on the source
connection's `search_path`, matching PostgreSQL's unqualified resolution. Use
OID order as a deterministic fallback when no candidate is visible. Leave
cached-name and OID lookups unchanged. This does not attempt to fix downstream
type-name qualification or DDL generation.
### Before / after and compatibility
- Before: a duplicate type name can resolve to a hidden schema's OID,
depending on row order.
- After: the visible type is chosen; when none is visible, the fallback is
deterministic.
- No configuration or public API change. Jobs that depended on the
unspecified selection of a hidden type may observe a different OID; that is the
intended correction.
### Validation
The real-PostgreSQL regression
`PostgresCDCIT#shouldResolveNewTypesUsingPostgresSearchPath` passes (1 test, 0
failures). The scoped PostgreSQL CDC connector tests also passed (70 tests).
Full repository CI remains for the PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
