Data Connect ignores datasource.postgresql.schema and always qualifies objects with public #9270
andersonllda
started this conversation in
General
Replies: 1 comment
-
I opened a bug i think its more apropriate |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Firebase Data Connect appears to ignore the schema property under datasource.postgresql in dataconnect.yaml and continues to generate SQL that explicitly references objects in the public schema (e.g. "public"."vw_bible_faiths_localized"). Because the runtime SQL is explicitly qualified with public, the configured search_path or granting permissions does not fix the problem. This makes it effectively impossible to use a different Postgres schema (for example bible_content) with Data Connect — the server continues to run queries against public and fails when objects live in another schema.
I will list everything we tested and all artifacts (configs, diffs, schema, steps) so this is reproducible.
Environment
firebase-tools version: 14.18.0
Data Connect serviceId: dailybiblepuzzle-service
location: us-east4
Cloud SQL / Postgres:
instanceId: dailybiblepuzzle-instance
database: dailybiblepuzzle-database
target schema with actual objects: bible_content
CLI commands used: firebase dataconnect:sql:diff, firebase dataconnect:sdk:generate, firebase deploy --only dataconnect (with --debug), firebase dataconnect:sql:apply
Tried UI: VS Code Data Connect extension (Add SDK to App) and CLI.
What I configured locally
dataconnect/dataconnect.yaml (relevant parts)
What actually happens (observed runtime / debug output)
When calling the published endpoint (or when running firebase dataconnect:sql:diff) the runtime generates SQL that references public explicitly. Example error payload returned by the Data Connect service:
Even though the view vw_bible_faiths_localized exists in bible_content schema (verified), the service is generating SQL against public and fails.
Many teams use schema separation in a single Postgres database (for organization, multitenancy, or separation of concerns). Data Connect should correctly honor the configured schema target or allow fully qualified schema.table names in the GraphQL mapping.
If Data Connect always qualifies objects with public (or interprets user-supplied names wrongly), it prevents safe adoption for systems that do not want to put objects into public.
Creating aliases in public is a poor workaround (duplication, maintenance, possible security exposure).
Thanks — we like the Data Connect concept a lot. We just need a way to map Data Connect to non "public" schemas (or confirmation of the intended behavior and documentation).
Beta Was this translation helpful? Give feedback.
All reactions