Added a new detector for catching unsupported COPY command structure

[ShivanshGahlot]

Describe the changes in this pull request

Reporting two unsupported query constructs related to COPY command:

• COPY FROM ... WHERE
• COPY ... ON_ERROR
  Report unsupported COPY command syntax #1991

Added a new detector CopyCommandUnsupportedConstructsDetector in detectors.go to report both these constructs

Currently the PR also contains changes related to pg_query_go v6 upgrades. Will rebase the PR to main once I merge that PR

Describe if there are any user-facing changes

The assessment report now reports these constructs under UQC:

How was this pull request tested?

Added new unit tests for these copy constructs in:
parser_issue_detector_test.go
issue_dml_test.go
detectors_test.go

An end to end test for the same construct needs to be added

Does your PR have changes that can cause upgrade issues?

Component	Breaking changes?
MetaDB	No
Name registry json	No
Data File Descriptor Json	No
Export Snapshot Status Json	No
Import Data State	No
Export Status Json	No
Data .sql files of tables	No
Export and import data queue	No
Schema Dump	No
AssessmentDB	No
Sizing DB	No
Migration Assessment Report Json	No
Callhome Json	No
YugabyteD Tables	No
TargetDB Metadata Tables	No

[makalaaneesh]

Simplified code from what I was discussing in the morning:
I tried running your tests and they all passed, but do take a deeper look!
cc: @sanyamsinghal @priyanshi-yb

	protoMsg := msg.Interface().(proto.Message)
	copyStmt := protoMsg.(*pg_query.CopyStmt)

	if copyStmt.IsFrom && copyStmt.WhereClause != nil {
		d.copyFromWhereConstructDetected = true
	}
	for _, option := range copyStmt.Options {
		defElemNode := option.GetDefElem()
		if defElemNode != nil {
			if defElemNode.Defname == "on_error" {
				d.copyOnErrorConstructDetected = true
				break
			}
		}
	}

[priyanshi-yb]

I think yes this makes sense. It reduces the number of lines and readable.

[sanyamsinghal]

Lets stick to protomsg for this codepath, reason being the required info is not directly availabe in the struct and extraction of defElem can be generic and reused multiple times.

It can be simplified like this using existing helper functions:

FromField := GetMessageField(msg, "is_from")
whereField := GetMessageField(msg, "where_clause")
if FromField != nil && whereField != nil {
     d.copyFromWhereConstructDetected = true
}

defNames := TraverseAndExtractDefNamesFromDefElem(msg)
if slices.Contains(defNames, "on_error") {
    d.copyOnErrorConstructDetected = true
}

Refer my PR for TraverseAndExtractDefNamesFromDefElem

[makalaaneesh]

just to be on the same page, there are two different issues here.

For the first one, isFrom and whereClause are directly available in CopyStmt struct, so would prefer dealing with the struct directly for that issue. But GetMessageField(msg, "is_from" isn't too bad either from a readability standpoint. I'll leave it up to you.

For the DefElem one, we can use the new function that Sanyam is introducing, but then you'll have to wait until that PR is merged.

[ShivanshGahlot]

I had to add a new function GetBoolField() for the is_from clause. I have used the GetMessageField and GetBoolField approach rn for the first one.
For the second one, I have used Sanyam's function in my PR.

[sanyamsinghal]

Lets stick to protomsg for this codepath, reason being the required info is not directly availabe in the struct and extraction of defElem can be generic and reused multiple times.

It can be simplified like this using existing helper functions:

FromField := GetMessageField(msg, "is_from")
whereField := GetMessageField(msg, "where_clause")
if FromField != nil && whereField != nil {
     d.copyFromWhereConstructDetected = true
}

defNames := TraverseAndExtractDefNamesFromDefElem(msg)
if slices.Contains(defNames, "on_error") {
    d.copyOnErrorConstructDetected = true
}

Refer my PR for TraverseAndExtractDefNamesFromDefElem

[sanyamsinghal]

Also please add some simple end to end tests, just to cover - final assessment report is getting populated with the required info.

[sanyamsinghal]

LGTM.
If you are planning to add end-to-end tests later, then do file a ticket for that.

[sanyamsinghal]

see if the tests for this can be at one place only either in detectors.go or parse_issue_detector_test.go

Currently we have the tests distributed among these two files, but since they are essentially testing the same thing, we can just have it one place.

[ShivanshGahlot]

Yeah for now I have added the tests but commented out the sql of CREATE ... ON_ERROR since it is supported only on PG17. Have added a ticket to do the same:
#2119

[ShivanshGahlot]

Removed the tests from detectors_test.go. The tests are same anyways. They were helpful in development.