Table's distribution characteristics declarative, in CREATE TABLE

I'm wondering if there is or has been a desire to make distributed-ness of tables declarative; that is, part of the CREATE TABLE statement and processed as part of the CREATE TABLE operation.

If something extra in the table definition could be used to indicate distribution method, partition column, shard count, and replication factor (and maybe the colocation relationships when those are added), then the multi-planner could extract those values from the "extra thing"; then it would discard the extra thing from the table definition, and proceed with a standard table create followed by the operations to create_distributed_table() and create_worker_shards(). CREATE TABLE statements that lack this extra thing would result in an error (if only distributed non-temp tables are allowed in Citus).

In PG <= 9.5 the only possibility I can imagine is to involve a dummy column of a new data type `citus.distributed('hash', partition_col, 8, 1)`, which could store all of the needed info in the typmod int32 of the data type. CREATE TABLE statements that lacked a column with type citus.distributed would result in an error. But the typmod in32 is too small to be able to include a usable reference to the partition column (only available as a cstring and no lookup on the table definition is possible) plus the other values. So <= 9.5 it doesn't seem possible.

In PG >= 9.6, Citus could define a new `ACCESS METHOD` whose entire job is to allow `CREATE TABLE` statements to include `INDEX (partition_col) USING distributed WITH (method='hash', shard_count=8, replication_factor=1)`. The index itself wouldn't be created, and no standalone `CREATE INDEX ... USING distributed` would be allowed by the multi-planner. The access method only exists to allow the configuration values ("storage parameters" in this case) to reach the multi-planner; the index definition is then discarded. Or, alternately, the index _is_ created so that it shows up via reflection in pg_catalog metadata, but does not participate in query plans because of the access method implementation.