Should `DFSchema::datatype_is_logically_equal` be extended with more logical equality?

[Jefffrey]

Apparently this function considers utf8 & utf8view types to be logically equal:

datafusion/datafusion/common/src/dfschema.rs

Lines 668 to 675 in f27e50c

	/// Checks if two [`DataType`]s are logically equal. This is a notably weaker constraint
	/// than datatype_is_semantically_equal in that different representations of same data can be
	/// logically but not semantically equivalent. Semantically equivalent types are always also
	/// logically equivalent. For example:
	/// - a Dictionary<K,V> type is logically equal to a plain V type
	/// - a Dictionary<K1, V1> is also logically equal to Dictionary<K2, V1>
	/// - Utf8 and Utf8View are logically equal
	pub fn datatype_is_logically_equal(dt1: &DataType, dt2: &DataType) -> bool {

datafusion/datafusion/common/src/dfschema.rs

Lines 726 to 729 in f27e50c

	// Utf8 and Utf8View are logically equivalent
	(DataType::Utf8, DataType::Utf8View) => true,
	(DataType::Utf8View, DataType::Utf8) => true,
	_ => Self::datatype_is_semantically_equal(dt1, dt2),

This raises the question of it we should extend it for more logical equality. For example:

• binary & binaryview should be logically equivalent
• should largeutf8, utf8, and utf8view all be logically equivalent? (and also for binary, including fixedsizebinary)
• what about list, largelist, listview, largelistview?

Origin PR:

• fix(substrait): fix regressed edge case in renaming inner struct fields #15634