Support PROTO, ENUM

[apstndb]

This PR adds decoder logic for PROTO and ENUM.

spanner> WITH t AS (SELECT CAST('genre: POP, nationality: "Japan"' AS spanner.examples.music.SingerInfo) AS singer)
      -> SELECT t.singer, t.singer.genre, CAST(t.singer AS STRING) AS singer_string, CAST(t.singer.genre AS STRING) AS genre_string
      -> FROM t;
+--------------+-------+---------------------------------+--------------+
| singer       | genre | singer_string                   | genre_string |
+--------------+-------+---------------------------------+--------------+
| GgVKYXBhbiAA | 0     | nationality: "Japan" genre: POP | POP          |
+--------------+-------+---------------------------------+--------------+

Update dependency because it depends on "spanner: Add support for Proto Columns" in spanner client v1.62.0

fixes #174

[apstndb]

I am wondering that proto test case can be undeterministic(not canonical).

[yfuruyama]

Thank you for filing this PR. I left a comment about how spanner-cli should handle the proto column. Let's discuss in the comment.

[yfuruyama]

Do we need these test cases?

I think spanner-cli should handle the proto column just as an arbitrary byte sequences (similar to BYTE column) and I'm not sure if we should take care of the validness of the parsed content (I feel it's a job for Spanner server test case).

[apstndb]

Thank you. It is a fair comment.
This is a legacy of trying to put this test case into a table-driven test for TestDecodeColumn.

What we really want to test here is the following:

• No error occurs
• It is not mistakenly treated as NULL or an empty byte string
• The input byte sequence does not change

Therefore, this test should simply test that the byte string is passed as is via spanner.GenericColumnValue.

[apstndb]

I think it is what we need.
8752da0

[apstndb]

I have noticed it can be written by table driven test using spanner.GenericColumnValue.

[apstndb]

rewrited af031a4

[apstndb]

If you don't want to contain testdata/protos, I can rewrite ENUM test cases using hand-writtenspanner.GenericColumnValue.

[yfuruyama]

Sorry I don't have enough time to review this. Next ETA: end of this week.

[yfuruyama]

Sorry for the delayed review.

If you don't want to contain testdata/protos, I can rewrite ENUM test cases using hand-written spanner.GenericColumnValue.

This is another approach, but how about using existing enum type which implements protoreflect.Enum interface from external module? For example, descriptorpb.Edition can be used for this purpose.

This is just for testing, so I think any enum is fine.

[yfuruyama]

I think we don't need to create a separate test function because spanner.NewRow accepts the spanner.GenericColumnValue as well.

ref: https://github.com/googleapis/google-cloud-go/blob/633dc86f615ee32c1ad1ec704bf6bc858a4d535c/spanner/value.go#L4424-L4428

[apstndb]

I think that I don't want to test spanner.NewRow and (*spanner.Row).Column, so TestDecodeColumnGCV is more cleaner unit tests.
But I don't want to rewrite all existing test cases in TestDecodeColumn to equivalent hand written spanner.GenericColumnValue, so I agree to merge new test cases into TestDecodeColumn.

[yfuruyama]

Maybe we can replace this with the following test to stop dependency on the imported proto?

		{
			desc: "null proto",
			value: spanner.GenericColumnValue{
				Type: &sppb.Type{
					Code: sppb.TypeCode_PROTO,
				},
				Value: structpb.NewNullValue(),
			},
			want: "NULL",
		},

[apstndb]

This is another approach, but how about using existing enum type which implements protoreflect.Enum interface from external module? For example, descriptorpb.Edition can be used for this purpose.

All options can test we want to test.
If I use a existing enum type, I feel a enum type in well-known protobuf types like Syntax is better than other types.

[apstndb]

I leave ProtoTypeFqn=examples.spanner.music.SingerInfo because I think this field won't be empty in real data.

[yfuruyama]

LGTM. Thank you for your work on this PR! I think now the implementation is much clearer.