sql: Fix incorrect handling of types

[shmsr]

Proposed commit message

This fixes the incorrect handling of types in SQL module. More details on the issue are present here: #40090

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• Test with Elasticsearch
• Test if valid inputs are treated correctly
• Test if there are other cases too

How to test this PR locally

As usual.

Related issues

• x-pack/metricbeat/module/sql: Problem with handling types properly #40090

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @shmsr? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[shmsr]

This is where based on types, key-vals are assigned under numeric, string or bool

[shmsr]

Sample output:

Before this patch:

 "sql": {
        "query": "select '0054321'::varchar(20) as strCol, 12345 as intCol",
        "metrics": {
            "numeric": {
                "strcol": 54321,
                "intcol": 12345
            }
        },
        "driver": "postgres"
    }

After this patch:

"sql": {
        "driver": "postgres",
        "query": "select '0054321'::varchar(20) as strCol, 12345 as intCol",
        "metrics": {
            "string": {
                "strcol": "0054321"
            },
            "numeric": {
                "intcol": 12345
            }
        }
    }

So this is behaviour change in how data is now stored in ES but it's the correct change that's fixing a bug. We have to account this as well. But the thing is VARCHAR fields is now coming correctly under "sql.metrics.string" object as it should.

[shmsr]

@AndersonQ / @faec Could you please review this PR? This is an important bugfix that requires immediate attention. Thank you for your help.

We are planning to get this merged ASAP to make it available for next release.

[devamanv]

One suggestion(not related to your changes though):
We seldom need a pointer to an interface, unless there's a specific use case for it. It's like using a pointer to a pointer to an underlying concrete type. Also, we could use the any alias, which denotes the blank interface type interface{}. Just a suggestion, see if we can try to improve this a bit.

[shmsr]

Yes, I agree with your point. There are many code smells that need to be addressed. I'll create a task and add it to our backlog.

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[cmacknz]

I have only skimmed this, approving to unblock.

Probably you could adjust the CODEOWNER so the data plane team isn't ping for this change next time.