Changes between Initial Version and Version 1 of Ticket #35778


Ignore:
Timestamp:
Sep 20, 2024, 1:24:19 PM (2 months ago)
Author:
john-parton
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #35778 – Description

    initial v1  
    66It is possible to use the native JSONObject with server side bindings, but it requires a little bit of use of `cast`.
    77
    8 See <commit missing, was force-pushed overwritten at some point, need to find it again>
     8See https://github.com/django/django/commit/0f53d48115ba0295cefea33512dc146caad39443
    99
    1010There are two minor issues:
    … …  
    12121. 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.
    13132. 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
    14 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.)
    15 2b. Update the Cast function to always wrap values in parenthesis in all contexts. This seems like overkill.
    16 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.
     14
     15Options for minor issue 2:
     16
     17 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.)
     18 b. Update the Cast function to always wrap values in parenthesis in all contexts. This seems like overkill.
     19 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.
Back to Top