changefeedccl: support CREATE DATABASE CHANGEFEED syntax

[KeithCh]

Add basic syntax support for database-level
changefeeds.
CREATE DATABASE CHANGEFEED for foo
This PR only allows the aforementioned statement
to be parsed; no changefeed is created.

Epic: CRDB-1421
Resolves: #147369

Release note: None

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

It looks like your PR touches SQL parser code but doesn't add or edit parser tests. Please make sure you add or edit parser tests if you edit the parser.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[blathers-crl]

It looks like your PR touches SQL parser code but doesn't add or edit parser tests. Please make sure you add or edit parser tests if you edit the parser.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[blathers-crl]

Your pull request contains more than 1000 changes. It is strongly encouraged to split big PRs into smaller chunks.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[asg0451]

some thoughts; also can you get someone from sql foundations to actually review the parser changes?

[asg0451]

i don't love having to do these assertions everywhere. is this (having target be an interface) the right abstraction?

[KeithCh]

I guess if we don't plan on supporting multiple types of targets per changefeed it's not really needed.

[KeithCh]

One benefit is that we don't have to modify the signature of functions that takes in tree.ChangefeedTargets, and the way we loop through them. If we didn't have the abstraction we would have to do something like

type ChangefeedTargets struct {
 ChangefeedDatabseTarget ChangefeedDatabseTarget[]
 ChangefeedTableTarget ChangefeedTableTargets[]
}

[mgartner]

Did you consider something like this instead, with validation on CREATE ... CHANGEFEED that ensures that all targets are the same level?

// ChangefeedTargets represents a list of database objects to be watched by a
// changefeed.
type ChangefeedTargets []ChangefeedTarget

// ChangefeedTarget represents a database-level or table-level changefeed
// target.
type ChangefeedTarget struct {
	// Name is the name of a database or table.
	Name
	// FamilyName is the name of a column family to be watched. It is the empty
	// string for database-level targets.
	FamilyName Name
}

[KeithCh]

That is possible, but we can't rely on FamilyName to determine whether it is a DB target. We might have with split_column_families set in which case it would be empty. It would have to be like

type ChangefeedTarget struct {
	// Name is the name of a database or table.
	Name
	// FamilyName is the name of a column family to be watched. It is the empty
	// string for database-level targets.
	FamilyName Name
	
	// TargetType is an enum (table, changefeed)
	TargetType ChangefeedTargetType
}

and then we check the TargetType when we work with the object.

But that doesn't seem very idomatic.

[mgartner]

Seems idiomatic to me, unless I'm missing something. Here's one example of a similar pattern:

cockroach/pkg/sql/sem/tree/with.go

Lines 14 to 32 in 9f61a38

	// CTE represents a common table expression inside of a WITH clause.
	type CTE struct {
	Name AliasClause
	Mtr CTEMaterializeClause
	Stmt Statement
	}
	// CTEMaterializeClause represents either MATERIALIZED, NOT MATERIALIZED, or an
	// empty materialization clause.
	type CTEMaterializeClause int8
	const (
	// CTEMaterializeDefault represents an empty materialization clause.
	CTEMaterializeDefault CTEMaterializeClause = iota
	// CTEMaterializeAlways represents MATERIALIZED.
	CTEMaterializeAlways
	// CTEMaterializeNever represents NOT MATERIALIZED.
	CTEMaterializeNever
	)

I'd bet there are more examples like this if you look around.

[KeithCh]

I was thinking that since FamilyName only exists for table targets it would be nice to have different structs to separate them. I'm ok with your approach if you think it is the best way.

[KeithCh]

Talked to @asg0451, we're going to have multiple fields inside CreateChangefeed to represent the different target types.

[mgartner]

Did you consider something like this instead, with validation on CREATE ... CHANGEFEED that ensures that all targets are the same level?

// ChangefeedTargets represents a list of database objects to be watched by a
// changefeed.
type ChangefeedTargets []ChangefeedTarget

// ChangefeedTarget represents a database-level or table-level changefeed
// target.
type ChangefeedTarget struct {
	// Name is the name of a database or table.
	Name
	// FamilyName is the name of a column family to be watched. It is the empty
	// string for database-level targets.
	FamilyName Name
}

[KeithCh]

bors r=asg0451

tftr!

[craig]

Build succeeded:

• check_generated_code
• unit_tests
• examples_orms
• local_roachtest
• linux_amd64_fips_build
• linux_amd64_build
• local_roachtest_fips
• lint
• acceptance
• docker_image_amd64