Distinguish jsonb[] array columns from scalar jsonb in ComplexHelper#13
Merged
Conversation
information_schema.columns surfaces both a plain `jsonb` column holding a
JSON-array *value* and a `jsonb[]` (Postgres ARRAY of jsonb) column
identically from the Python side: both hand recursive_convert a bare
Python list. _load_complex_type_from_colinfos previously collapsed both
cases to the same `Jsonb` sentinel, so recursive_convert always wrapped the
whole incoming list in one `Jsonb(...)` -- correct for the scalar-column
case, but wrong for jsonb[]: psycopg then tries to bind a single jsonb
value to an array column, and Postgres raises DatatypeMismatch ("column
... is of type jsonb[] but expression is of type jsonb").
Adds a distinct JsonbArray sentinel for the array-of-jsonb case, so
recursive_convert can tell "this list *is* the array" (wrap each element
in its own Jsonb(...)) apart from "this list is JSON content for one
scalar jsonb value" (wrap the whole thing once, unchanged from before).
Found via ccmt2's pgdevkit migration: printing.printtemplates.articles_to_print
is a jsonb[] column, and pg_upsert_dict's INSERT started failing with this
exact DatatypeMismatch once ccmt2's postgres.py moved onto
pgdevkit.db.crud/ComplexHelper.
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.
information_schema.columns surfaces both a plain
jsonbcolumn holding a JSON-array value and ajsonb[](Postgres ARRAY of jsonb) column identically from the Python side: both hand recursive_convert a bare Python list. _load_complex_type_from_colinfos previously collapsed both cases to the sameJsonbsentinel, so recursive_convert always wrapped the whole incoming list in oneJsonb(...)-- correct for the scalar-column case, but wrong for jsonb[]: psycopg then tries to bind a single jsonb value to an array column, and Postgres raises DatatypeMismatch ("column ... is of type jsonb[] but expression is of type jsonb").Adds a distinct JsonbArray sentinel for the array-of-jsonb case, so recursive_convert can tell "this list is the array" (wrap each element in its own Jsonb(...)) apart from "this list is JSON content for one scalar jsonb value" (wrap the whole thing once, unchanged from before).
Found via ccmt2's pgdevkit migration: printing.printtemplates.articles_to_print is a jsonb[] column, and pg_upsert_dict's INSERT started failing with this exact DatatypeMismatch once ccmt2's postgres.py moved onto pgdevkit.db.crud/ComplexHelper.