Generalize OPTIONS behavior

[apstndb]

Currently, memefish fails unknown option key in some OPTIONS.
OPTIONS key can be added without notification, and it is even possible to have undocument options.

I think it is better to have "schema on read" semantics rather than "schema on write(parse)" semantics.
Validation should be the responsibility of semantic analysis phase.

Proposed characteristics

• Any key-value pairs can be parsed and unparsed.
• Known key-value can be accessed by named methods.
  • It can be error if invalid value type, and the error can be handled.
  • These are maintained on a best effort basis.
• Concrete options share underlying implementation as GenericOptions.

[apstndb]

I implemented proposed behavior in #111

[makenowjust]

As said in #122 (comment), we can change AST definitions. Thus, we have another idea to introduce a new Options, the same as GenericOptions, and to replace existing XXXOptions types with this. In this case, we need to introduce the following utility functions.

func (o *Options) BoolField(name string) (bool, error) { ... }
func (o *Options) StringField(name string) (bool, error) { ... }
// ..., `IntField`, `FloatField`, and more.

(I'm not sure "field" is correct naming.)

IMHO, it is hard to maintain known key-value pairs.

[apstndb]

Your decision is very reasonable. There is one Options!
Only undecided spec may be the way to distinguish absent or explicit null using *Field method.
Generally, option's default is not same with Go/protobuf default value, and null means reset to default.

Real example

https://cloud.google.com/spanner/docs/reference/standard-sql/data-definition-language#create-sequence

• The default value os start_with_counter is 1.
• Explicit null means set to default(1).
• Absent means no changes to the specific key.
• 0 is not valid value.

spanner> SELECT * FROM INFORMATION_SCHEMA.SEQUENCE_OPTIONS WHERE OPTION_NAME = "start_with_counter";
Empty set (18.17 msecs)

spanner> ALTER SEQUENCE sch1.sequence SET OPTIONS(start_with_counter=1);
Query OK, 0 rows affected (9.30 sec)

spanner> SELECT * FROM INFORMATION_SCHEMA.SEQUENCE_OPTIONS WHERE OPTION_NAME = "start_with_counter";
+---------+--------+----------+--------------------+-------------+--------------+
| CATALOG | SCHEMA | NAME     | OPTION_NAME        | OPTION_TYPE | OPTION_VALUE |
+---------+--------+----------+--------------------+-------------+--------------+
|         | sch1   | sequence | start_with_counter | INT64       | 1            |
+---------+--------+----------+--------------------+-------------+--------------+
1 rows in set (31.25 msecs)

spanner> ALTER SEQUENCE sch1.sequence SET OPTIONS(sequence_kind="bit_reversed_positive");
Query OK, 0 rows affected (9.80 sec)

spanner> SELECT * FROM INFORMATION_SCHEMA.SEQUENCE_OPTIONS WHERE OPTION_NAME = "start_with_counter";
+---------+--------+----------+--------------------+-------------+--------------+
| CATALOG | SCHEMA | NAME     | OPTION_NAME        | OPTION_TYPE | OPTION_VALUE |
+---------+--------+----------+--------------------+-------------+--------------+
|         | sch1   | sequence | start_with_counter | INT64       | 1            |
+---------+--------+----------+--------------------+-------------+--------------+
1 rows in set (13.09 msecs)

spanner> ALTER SEQUENCE sch1.sequence SET OPTIONS(start_with_counter=0);
ERROR: rpc error: code = FailedPrecondition desc = Sequence sch1.sequence has invalid start_with_counter option: 0.  `start_with_counter` has to be a positive INT64 number.
spanner> ALTER SEQUENCE sch1.sequence SET OPTIONS(start_with_counter=null);
Query OK, 0 rows affected (8.69 sec)

spanner> SELECT * FROM INFORMATION_SCHEMA.SEQUENCE_OPTIONS WHERE OPTION_NAME = "start_with_counter";
Empty set (15.76 msecs)

[apstndb]

I have researched documented options in GoogleSQL data definition language.

object_type	option_name	option_type
DATABASE	default_leader	STRING
DATABASE	optimizer_version	INTEGER
DATABASE	optimizer_statistics_package	STRING
DATABASE	version_retension_perios	STRING
PLACEMENT	instance_partition	STRING
PLACEMENT	default_leader	STRING
COLUMN	allow_commit_timestamp	BOOL
SEARCH INDEX	sort_order_sharding	BOOL
SEARCH INDEX	disable_automatic_uid_column	BOOL
CHANGE STREAM	retention_period	STRING
CHANGE STREAM	value_capture_type	STRING
CHANGE STREAM	exclude_ttl_deletes	BOOL
CHANGE STREAM	exclude_insert	BOOL
CHANGE STREAM	exclude_update	BOOL
CHANGE STREAM	exclude_delete	BOOL
STATISTICS	allow_gc	BOOL
MODEL	endpoint	STRING
MODEL	endpoints	ARRAY<STRING>
MODEL	default_batch_size	INTEGER
VECTOR INDEX	distance_type	INTEGER
VECTOR INDEX	tree_depth	INTEGER
VECTOR INDEX	num_leaves	INTEGER
VECTOR INDEX	num_branches	INTEGER

IntegerField, StringField, BoolField cover all usecases except endpoints.
I think ArrayStringField is not needed, because there are general solution like below:

• Provide (*Options).Field(string) (Expr, bool)
• Manually find using Options.Records []*OptionsRecord

I think it is not bad idea to provide Field method because it is possible that a new key-value pair have other type, and its function can be used to implement typed *Field methods.

[makenowjust]

@apstndb If you work on this issue, I'd like you to make a new PR separated from other topics for reviewing.

[apstndb]

Ok, I'll make another PR to add Options and migrate existing options to Options.