markhoerth opened a new issue, #10520: URL: https://github.com/apache/gravitino/issues/10520
### Describe the feature Support SET PROPERTY on tables in the jdbc-postgresql catalog (and JDBC catalogs generally). Custom user-defined properties should be stored in Gravitino's own metadata layer rather than being pushed down to the underlying JDBC database. ### Motivation A natural and valuable integration pattern is writing metadata back to Gravitino from external tools like dbt. After a dbt run, lineage (upstream tables, model FQN) and quality results (test pass/fail counts, quality status) should be visible on the corresponding Gravitino tables so that any system reading from the catalog — AI agents, BI tools, data contracts — can see the same quality signal. Currently, attempting to set properties on a jdbc-postgresql table returns: "Set property is not supported yet" This blocks write-back integrations entirely for JDBC-backed catalogs, which are among the most common catalog types in enterprise deployments. ### Describe the solution Custom/user-defined properties (e.g. dbt.quality.status, dbt.upstream_tables) have no meaningful mapping to PostgreSQL or any JDBC database. They should be stored in Gravitino's own metadata store, not pushed down to the underlying database. This is analogous to how Gravitino stores tags — in its own layer, independent of the underlying catalog implementation. A reasonable approach: distinguish between connector-managed properties (e.g. storage format, partitioning) which are pushed down, and user-defined properties which are stored in Gravitino's metadata store. ### Additional context Workaround: Tags can be applied to JDBC-backed tables and work correctly. However tags are not key-value pairs and cannot carry structured metadata like test counts, timestamps, or upstream table lists. Property write-back works correctly on non-JDBC catalogs (Iceberg, Hive). This issue affects all JDBC catalog providers, not just PostgreSQL. Related: https://github.com/apache/gravitino/issues/10519 -- 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]
