@r1b

I appreciate your interest in our project and am grateful for you effort to put together this PR.

I see that it attempts to build upon the work that was found in PR #1130.

I also see that we have then attempted to add a number of other elements above and beyond that.

We are currently at 350+ lines of new code. I have not had a chance to dive deeply into this code, so my apologies. I have several questions (some of these are more rhetorical so don't feel as though you need to respond to each of them ... this is mostly me thinking out loud).

• Does ALL of this have to be in a single PR?
• Do ALL of these edits create a single atomic unit of change?
• Could we simplify the process of creating, reviewing, editing, and approving this work by limiting it to small discrete units of change per PR? (I am the sole full-time maintainer of this task and need to try and balance my commitments appropriately).

If we were to break this into small units of change:

• what are the most important elements? (what are optional)
• what order makes sense for implementation? (most important OR foundational work first, least important work last).
• do we have appropriate tests for each unit of change?

What are your thoughts?

Yep, happy to break this up (more of a conversation-starter vs expecting to get all of this in :)) - I think the right sequencing is something like:

• Add the JSON type (what we have in Add JSON type compiler support #1130, with added tests)
• Add the json_serializer / json_deserializer dialect kwargs (expected for all JSON implementors)

This will unblock users who want to reference a JSON column in table definitions / query results w/o indexing

• Add JSONPath indexing, comparator support

This will allow users to generate queries that reach into the JSON column to pull out subfields + generate appropriate derived types for those expressions

^ For my own use case, these two are satisfactory

• (Optional) Support JSON query parameters

Optional because this is probably a niche use case / requires workarounds for missing dbapi support - instead, we could just disallow this.

This will allow users to pass a JSON object as a query parameter, with appropriate type conversions when generating SQL

• (Optional) Support JSONPath modes

Optional because this is a preview feature - OK to wait until this is GA / requested by user

This will allow users to use lax / lax recursive modes in generated JSON path expressions

Closing in favor of #1147 - I pulled out a smaller PR from the rough sequencing above