#35778: Use native JSONObject on Postgres 16+ with server side bindings
-------------------------------------+-------------------------------------
Reporter: john-parton | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by john-parton:
Old description:
> JSONObject on Postgres 16 with server side bindings recently resulted in
> a crash. The most recent fix is to fallback to the use of
> jsonb_build_object on postgres 16 when using server side bindings.
>
> See https://code.djangoproject.com/ticket/35734
> And https://github.com/django/django/pull/18549
>
> It is possible to use the native JSONObject with server side bindings,
> but it requires a little bit of use of `cast`.
>
> See <commit missing, was force-pushed overwritten at some point, need to
> find it again>
>
> There are two minor issues:
>
> 1. Should Postgres 16 *without* server-side bindings use "cast" even
> though it's not strictly necessary? It it desirable or preferable to keep
> the generated SQL the same when toggling the server-side binding feature?
> I mentioned digging through logs as one example where it might matter.
> 2. Use of both cast and native json will require at least a minor change
> to escaping. This is because we use the double-colon operator to cast and
> the native json syntax uses a single colon to separate key-value pairs.
> This creates a parsing ambiguity which results in a syntax error (on at
> least one version of postgres). For solutions, they're all pretty similar
> 2a. Update the `as_native` function to wrap the keys in parenthesis,
> effectively resolving the ambiguity. (This does raise yet another
> question, a question within a question: should we go ahead and wrap the
> keys in parenthesis on ALL backends? I think Oracle doesn't necessary
> require that for example.)
> 2b. Update the Cast function to always wrap values in parenthesis in all
> contexts. This seems like overkill.
> 2c. Change postgres from using the double-colon operator to the CAST(x AS
> type) syntax. This also seems like overkill, and results in sql being
> generated that is less postgres-y, if that makes sense.
New description:
JSONObject on Postgres 16 with server side bindings recently resulted in a
crash. The most recent fix is to fallback to the use of jsonb_build_object
on postgres 16 when using server side bindings.
See https://code.djangoproject.com/ticket/35734
And https://github.com/django/django/pull/18549
It is possible to use the native JSONObject with server side bindings, but
it requires a little bit of use of `cast`.
See
https://github.com/django/django/commit/0f53d48115ba0295cefea33512dc146caad39443
There are two minor issues:
1. Should Postgres 16 *without* server-side bindings use "cast" even
though it's not strictly necessary? It it desirable or preferable to keep
the generated SQL the same when toggling the server-side binding feature?
I mentioned digging through logs as one example where it might matter.
2. Use of both cast and native json will require at least a minor change
to escaping. This is because we use the double-colon operator to cast and
the native json syntax uses a single colon to separate key-value pairs.
This creates a parsing ambiguity which results in a syntax error (on at
least one version of postgres). For solutions, they're all pretty similar
Options for minor issue 2:
a. Update the `as_native` function to wrap the keys in parenthesis,
effectively resolving the ambiguity. (This does raise yet another
question, a question within a question: should we go ahead and wrap the
keys in parenthesis on ALL backends? I think Oracle doesn't necessary
require that for example.)
b. Update the Cast function to always wrap values in parenthesis in all
contexts. This seems like overkill.
c. Change postgres from using the double-colon operator to the CAST(x AS
type) syntax. This also seems like overkill, and results in sql being
generated that is less postgres-y, if that makes sense.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35778#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107019210ad8401-4e330179-963d-45d3-82bf-a48bc83452c9-000000%40eu-central-1.amazonses.com.
