sql: relax restrictions on partition name reuse

[solongordon]

Previously, we did not allow users to reuse partition names between
different indexes on the same table. The reason for this was that it
caused some ambiguity with the zone specifiers passed to the cockroach zone CLI. However, that CLI has now been removed in favor of more
explicit SQL statements, so this is no longer an issue. I removed this
restriction, so partition names now only need to be unique per index,
not per table.

My original intent was to do away with the CLI zone specifiers (also
known as zone names) entirely, since they are no longer specified by
users in any command. However, there are a few places that rely on
having a string identifier for each zone. One is the event log, which
logs an event whenever a zone configuration is set or removed. Another
is the 'SHOW ZONE CONFIGURATIONS' command, which includes a zone_name
column for each row. (We could remove this but I think readability would
suffer.) The Admin UI uses zone name as well in its proto interface,
though I'm not sure if it's actually displayed anywhere in the UI.

So rather than removing zone names, I decided to keep them around only
as a display identifier. I removed any logic which relied on parsing a
zone name into a ZoneSpecifier. I also added explicit columns to the
crdb_internal.zones table for database_name, table_name, etc. to avoid
reliance on the zone_name for JOINs and such. I also removed any
references to "CLI specifiers."

The zone name for a partition on a secondary index takes the form
DATABASE.TABLE@INDEX.PARTITION. This was previously a disallowed format
for CLI specifiers, which either specified an index or a partition.

Finally, please note that it is no longer possible to alter a secondary index
partition using the ALTER PARTITION ... OF TABLE command. Users must
use ALTER PARTITION ... OF INDEX instead.

Release note (sql change): Partition names can now be reused between
different indexes on the same table.

[cockroach-teamcity]

This change is 

[rohany]

Why does alter partition of table ... need to be removed?

Reviewed 11 of 19 files at r1.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @danhhz and @rohany)

[solongordon]

It wasn't removed entirely. It's just you can only use that command to alter partitions on the primary index now. Otherwise it's ambiguous: if you have a partition named p on multiple indexes and run ALTER PARTITION p OF TABLE, which one did you mean to alter?

[rohany]

That makes sense

[rohany]

This looks pretty good to me, most of the changes are in deleting stuff from old tests. Restructuring the zones table like this definitely makes it much more usable in other contexts.

Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @danhhz)

[danhhz]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @danhhz and @solongordon)

---

pkg/sql/logictest/testdata/logic_test/crdb_internal, line 206 at r2 (raw file):

SELECT * FROM crdb_internal.zones WHERE false
----
zone_id  zone_name  range_name  database_name  table_name  index_name  partition_name  config_yaml  config_sql  config_protobuf

we implicitly test this table by using it in SHOW PARTITIONS, but I don't see anywhere that you had to update something testing it directly. should we?

[solongordon]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @danhhz)

---

pkg/sql/logictest/testdata/logic_test/crdb_internal, line 206 at r2 (raw file):

Previously, danhhz (Daniel Harrison) wrote…

we implicitly test this table by using it in SHOW PARTITIONS, but I don't see anywhere that you had to update something testing it directly. should we?

Yes, good point, I'll add a test.

[solongordon]

TFTRs!

bors r+

[craig]

Build succeeded

• GitHub CI (Cockroach)