Should the duckdb-go-bindings package be removed?

[VGSML]

I want to start topic to discuss. Since the duckdb-go package is a part of duckdb, do we need to have a separate package for bindings? We have duckdb-go/mappings and duckdb-go/arrowmappings packages, that have not any logic just type aliases for the bindings. After latest changes duckdb-go-bindings also has the duckdb-arrow build tag.

It looks like we don't need the duckdb-go-bindings any more, isn't it?

[taniabogatsch]

We have plans to also use the duckdb-go-bindings as a package/baseline to build Go extensions upon. We're still looking into possibilities there. Also, the separation allows to have a thin wrapper around the C API functions and duckdb-go as a "feature" package. I.e., other packages can build on top of duckdb-go-bindings, without having to deal with C code.

[VGSML]

Maybe it would better to have all go duckdb packages in one repo duckdb-go? There are a lot of duckdb repos.

Wow, it will be nice to have the go package to build extension. In the airpot-go I will work on filter pushdown - it's serialized to json duckdb internal array of filter struct, and I can't find any description of structure, values and so on, only in source code.
Maybe you can advise me. It looks like:

{
  "filters": [
    {
      "expression_class": "BOUND_CONJUNCTION",
      "type": "CONJUNCTION_OR",
      "alias": "",
      "query_location": 74,
      "children": [
        {
          "expression_class": "BOUND_OPERATOR",
          "type": "COMPARE_IN",
          "alias": "",
          "query_location": 55,
          "return_type": {
            "id": "BOOLEAN",
            "type_info": null
          },
          "children": [
            {
              "expression_class": "BOUND_COLUMN_REF",
              "type": "BOUND_COLUMN_REF",
              "alias": "title",
              "query_location": 49,
              "return_type": {
                "id": "VARCHAR",
                "type_info": null
              },
              "binding": {
                "table_index": 0,
                "column_index": 0
              },
              "depth": 0
            },
            {
              "expression_class": "BOUND_CONSTANT",
              "type": "VALUE_CONSTANT",
              "alias": "",
              "query_location": 18446744073709552000,
              "value": {
                "type": {
                  "id": "VARCHAR",
                  "type_info": null
                },
                "is_null": false,
                "value": "a"
              }
            },
            {
              "expression_class": "BOUND_CONSTANT",
              "type": "VALUE_CONSTANT",
              "alias": "",
              "query_location": 18446744073709552000,
              "value": {
                "type": {
                  "id": "VARCHAR",
                  "type_info": null
                },
                "is_null": false,
                "value": "b"
              }
            },
            {
              "expression_class": "BOUND_CONSTANT",
              "type": "VALUE_CONSTANT",
              "alias": "",
              "query_location": 18446744073709552000,
              "value": {
                "type": {
                  "id": "VARCHAR",
                  "type_info": null
                },
                "is_null": false,
                "value": "c"
              }
            }
          ]
        },
        {
          "expression_class": "BOUND_COMPARISON",
          "type": "COMPARE_GREATERTHAN",
          "alias": "",
          "query_location": 83,
          "left": {
            "expression_class": "BOUND_COLUMN_REF",
            "type": "BOUND_COLUMN_REF",
            "alias": "score",
            "query_location": 77,
            "return_type": {
              "id": "FLOAT",
              "type_info": null
            },
            "binding": {
              "table_index": 0,
              "column_index": 1
            },
            "depth": 0
          },
          "right": {
            "expression_class": "BOUND_CONSTANT",
            "type": "VALUE_CONSTANT",
            "alias": "",
            "query_location": 18446744073709552000,
            "value": {
              "type": {
                "id": "FLOAT",
                "type_info": null
              },
              "is_null": false,
              "value": 500
            }
          }
        }
      ]
    }
  ],
  "column_binding_names_by_index": [
    "title",
    "score",
    "post_time"
  ]
}

[VGSML]

like in the arrow?

[taniabogatsch]

Ah I am afraid that I am the wrong person to ask around filter pushdown, I have not worked much with that myself.

[VGSML]

ok, will investigate.

[taniabogatsch]

Maybe it would better to have all go duckdb packages in one repo duckdb-go? There are a lot of duckdb repos.

I'd love to merge the mapping repositories with duckdb-go - we might end up with more files in the top-level directory, but that would save us one tagged module.

W.r.t. merging duckdb-go-bindings and duckdb-go: I'd rather avoid that. Currently, next to potential other uses of duckdb-go-bindings, we're also getting close to GitHubs repository size limit (500MB) with all the shipped pre-build binaries. If we keep that in an extra repository, then we have a bit more slack there.

[VGSML]

Good point about size.