Skip to content

feat: default schema configuration for postgresql #3668

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

prog8
Copy link

@prog8 prog8 commented Oct 21, 2024

related to #3663

@kyleconroy
Copy link
Collaborator

Thanks for taking the time to contribute a PR.

The tests are currently broken. Could you take a look at the failures and se what's up?

@prog8 prog8 force-pushed the pg-default-schema branch from 0124613 to 3c9e7d6 Compare December 19, 2024 16:35
@dosubot dosubot bot added the size:S This PR changes 10-29 lines, ignoring generated files. label Dec 19, 2024
@prog8
Copy link
Author

prog8 commented Dec 19, 2024

@kyleconroy test pass. Thanks

@prog8
Copy link
Author

prog8 commented Dec 27, 2024

@kyleconroy should I add something more here?

@ecasilla
Copy link

+1

@prog8
Copy link
Author

prog8 commented Mar 11, 2025

ping @kyleconroy

@prog8
Copy link
Author

prog8 commented Mar 31, 2025

@kyleconroy any chance to merge it?

@jakob-lilliemarck
Copy link

We're also using sqlc with a Posgres database with multiple schemas and would love to see this feature. +1

@jmfederico
Copy link

Oh we so need this!

@jmfederico
Copy link

@kyleconroy anything that is needed for this to happen?
Happy to help if so.

@zaibon
Copy link

zaibon commented May 7, 2025

I'm depending on these fixes for my use case. I'm currently using the fork from @prog8, but since #3916 my workflow is now broken. Is there any chance we can move this PR forward?

@sgielen
Copy link

sgielen commented May 26, 2025

@prog8 I'm currently experimenting with versioned schemas as maintained by pgroll. In this scenario, pgroll maintains a secret schema containing the columns used by multiple schema versions, and then exposes a schema called (for example) version_a containing only views, and another schema called version_b containing only views.

Now, I'd like to run sqlc generate specifically on the version_b schema. For this, it's necessary to pass it through sqlc in a way other than the config file. I think it makes sense to use environment variables for this, just like with the database URL - in fact, we could even take the schema_version parameter from the database URL. I think this might make more sense than putting the schema version in the config file (or perhaps we could support both). What do you think about this?

See #3668 for a first, brute-force attempt at this, which does work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:S This PR changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants