You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the introduction of include key as clause, we agree that kafka key will always be ingested as raw bytea and further decoding into text / json will be handled with SQL expressions.
The old logic of decoding key according to schema registry should be completely cleaned up. For now it still tries to read schema registry and reports an error when it is not found. But the schema is never used for decoding.
Note: format debezium encode avro is still reading key schema from registry.
The text was updated successfully, but these errors were encountered:
After the introduction of
include key as
clause, we agree that kafka key will always be ingested as rawbytea
and further decoding into text / json will be handled with SQL expressions.convert_from('\x613141'::bytea, 'utf8')
->'a1A'::varchar
convert_from('\x7b2279656172223a323032347d'::bytea, 'utf8')::jsonb
->'{"year": 2024}'::jsonb
convert_from('\x313233'::bytea, 'utf8')::int8
->123::int8
int8recv('\x000000000000007b'::bytea)
->123::int8
The old logic of decoding key according to schema registry should be completely cleaned up. For now it still tries to read schema registry and reports an error when it is not found. But the schema is never used for decoding.
Note:
format debezium encode avro
is still reading key schema from registry.The text was updated successfully, but these errors were encountered: