JSON plugin interop?

[kswope]

What do you want to change?

I can't find it anywhere, is there a plugin setting for communicating with a plugin via JSON rather than protobuf?

What database engines need to be changed?

No response

What programming language backends need to be changed?

No response

[kyleconroy]

There currently isn't a way to do this. I'm a bit hesitant to add it, as it's difficult to ensure backwards compatibility.

What language are you using? I'd be happy to help you get set up. There's also a plugin that outputs the codegen request as JSON.

[kswope]

This is what I'm trying now, I found it here but doesn't imply "plugin" in any way, it generates codegen_request.json

      "gen": {
        "json": {
          "out": "."
        }
      }

This is whats on the plugins page, its very confusing that it does the same thing, I think it might be out of date documentation. (btw, "codegen" isn't documented anywhere)

{
  "version": "2",
  "plugins": [
    {
      "name": "jsonb",
      "process": {
        "cmd": "sqlc-gen-json"
      }
    }
  ],
   "sql": [
    {
      "schema": "schema.sql",
      "queries": "query.sql",
      "engine": "postgresql",
      "codegen": [
        {
          "out": "gen",
          "plugin": "jsonb",
          "options": {
            "indent": "  ",
            "filename": "codegen.json"
          }
        }
      ]
    }
  ]
}

Anyway, if the output from the first config is all I need, then all I need is to let sqlc do the heavy lifting and I can get started on some templeting.

The reason I was looking into making a "plugin" is because I didn't want this potentially stale, possibly confusing, otherwise meaningless to the user, json output file sitting around.

Suggestion: maybe offer this option

      "gen": {
        "json": {
          "stdout": true
        }
      }

This raises the question, why not support every language this way? sqlc does the heavy lifting, and pipes the metadata to plugins written in their own language. It just seems counterproductive to the community to write kotlin/python/typescript/etc support in go.

Btw what I'm doing is experimenting with using sqlc with rescript. Using intermediate JSON might be the solution now, but writing go to output rescript would simply never happen, not only because nobody uses rescript, but the two languages are natural enemies :)

[kyleconroy]

This raises the question, why not support every language this way? sqlc does the heavy lifting, and pipes the metadata to plugins written in their own language. It just seems counterproductive to the community to write kotlin/python/typescript/etc support in go.

This is how plugin support works today, but instead of JSON you need to use Protobuf. An example of a process-based plugin can be found here: https://github.com/kyleconroy/sqlc/tree/main/cmd/sqlc-gen-json

Instead of outputting JSON, you can change that plugin to output anything you'd like. It also doesn't need to be written in Go. Your plugin just needs to be able to parse Protobuf from Stdin.