Add pg 16 to CI and remove :generic explain plan option
#606
Conversation
This file contains 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 got PG 16 to work on the CI. The issue is we use the image tags
16.0,11.1, etc. As of Postgres 16 this tries to get the debian image instead of alpine. Appending-alpineto the tag name fixes it. I added it to all the old ones as well so that no one wonders why some have-alpineand some don't, in the future.At the same time, adding these tests uncovered an issue supporting Postgres's built-in generic option. The issue is we have to send a query with placeholders without sending the actual parameter values. For example we have to send
But if we send the parameter values they will be used in the explain plan. If we don't send the parameter values then we get into issues with Postgrex because it checks to make sure we have the right number of params. We get an error like this
I'm not really convinced it's worth digging into the guts of Postgrex just for this one explain option when we already have a workaround. And even if we could alter Postgrex for this case, I'm not sure Postgres will work as we expect. So I am suggesting to remove that option.