feat: let a postgres preset declare the extensions its image can create - #10
Merged
Conversation
An engine's image ships extensions that its databases mostly do not have. timescaledb worked around that with a site_init exec, which runs once per project when lerd env detects the service and names only the app database, so the testing one never got it and a snapshot restore, which drops and recreates, took it away again. pgvector had nothing at all, so vector was only ever created by hand, on an image installed for that one reason. The declaration replaces the workaround with something lerd can read rather than just execute. An entry marked always is created wherever lerd creates a database, so both databases of a project get it and a recreated one comes back whole. The types are what an import matches a dump against, so a dump reaching for a vector column brings the extension with it instead of failing on a type that does not exist, which is the usual shape of a dump from a managed provider, where pg_dump leaves out the extensions the connecting user does not own. timescaledb keeps its site_init line for now. Presets reach installed users within a day and binaries do not, so removing it before the release that understands extensions would leave timescale sites with neither.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An engine's image ships extensions that its databases mostly do not have.
postgres-timescaledbworked around that with asite_initexec, which runs once per project whenlerd envdetects the service and names only the app database, so the testing one never got it and a snapshot restore, which drops and recreates, took it away again.postgres-pgvectorhad nothing at all, sovectorwas only ever created by hand, on an image installed for that one reason.The declaration replaces the workaround with something lerd can read rather than just execute. An entry marked
alwaysis created wherever lerd creates a database, so both databases of a project get it and a recreated one comes back whole. Thetypesare what an import matches a dump against, so a dump reaching for avectorcolumn brings the extension with it instead of failing on a type that does not exist, which is the usual shape of a dump from a managed provider, wherepg_dumpleaves out the extensions the connecting user does not own.postgres-timescaledbkeeps itssite_initline for now. Presets reach installed users within a day and binaries do not, so removing it before the release that understandsextensionswould leave timescale sites with neither.Needs lerd-env/lerd#1139, which adds the field. Until that ships the entries are inert, so this can land in either order.