database: Use database.ParseDialect to accept dialect aliases and return canonical dialect (closes #917)#1021
Open
globalchubby wants to merge 7 commits intopressly:mainfrom
Open
database: Use database.ParseDialect to accept dialect aliases and return canonical dialect (closes #917)#1021globalchubby wants to merge 7 commits intopressly:mainfrom
globalchubby wants to merge 7 commits intopressly:mainfrom
Conversation
globalchubby
commented
Dec 28, 2025
| d = DialectTurso | ||
| case "starrocks": | ||
| d = DialectStarrocks | ||
| case "dsql": |
Author
There was a problem hiding this comment.
This case is new. The lookup map in NewStore has an entry for it, so we should support it here as well.
globalchubby
commented
Dec 28, 2025
| // Dialect is the type of database dialect. | ||
| type Dialect string | ||
|
|
||
| var ErrUnknownDialect = errors.New("unknown dialect") |
Author
There was a problem hiding this comment.
Since we're returning the same error in two places, I thought it better to have a sentinel error. I debated having an error type instead, but the only data I could think of it holding is the unknown dialect, but the caller already has this.
globalchubby
commented
Dec 28, 2025
| // aliases, e.g. "postgres" or "pgx". Use this function to ensure that a [Dialect] instance | ||
| // passed to any function that accepts a [Dialect] is a valid [Dialect]. | ||
| func ParseDialect(s string) (d Dialect, err error) { | ||
| // Every non-error return value from this function must have an entry in the [NewStore] lookup map. |
Author
There was a problem hiding this comment.
To really prevent drift, instead of having a comment here, what do you think of having a registry? I drafted up a PR in globalchubby#1.
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
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.
I think #917 highlights the issue that both
Dialectandstringcan represent a dialect, and both are accepted in public APIs. For example, compare the signatures ofgoose.SetDialectandgoose.NewProvider. This is a problem becauseDialectlooks like a valid enum, but it can actually be anystring.Long-term, it might be better to only accept strings in the public API, but that's a breaking change.
This PR adds a helper function
database.ParseDialectthat given astringreturns the correspondingDialectvalue, if any. It's used to fix #917, but by shifting the responsibility to Goose users: users using any public API that accepts aDialectcan obtain a validDialectvalue by callingParseDialect.I'm also wondering what you think these changes imply for
OpenDBDriver? I'm also curious about some of thedriverrewrites there which conflict with the logic inParseDialect, e.g.