If I understand this suggestion correctly it is a whole can of worms, as types that can never be null prevent us ever supporting outer joins that return these types.
I am strongly in favour of permitting the table definition forbidding nulls - and perhaps even defaulting to this behaviour. But I don’t think we should have types that are inherently incapable of being null. I also certainly don’t think we should have bifurcated our behaviour between types like this. > On 19 Sep 2023, at 11:54, Alex Petrov <al...@coffeenco.de> wrote: > > > To make sure I understand this right; does that mean there will be a default > value for unset fields? Like 0 for numerical values, and an empty vector (I > presume) for the vector type? > >> On Fri, Sep 15, 2023, at 11:46 AM, Benjamin Lerer wrote: >> Hi everybody, >> >> I noticed that the new Vector type accepts empty ByteBuffer values as an >> input representing null. >> When we introduced TINYINT and SMALLINT (CASSANDRA-895) we started making >> types non -emptiable. This approach makes more sense to me as having to deal >> with empty value is error prone in my opinion. >> I also think that it would be good to standardize on one approach to avoid >> confusion. >> >> Should we make the Vector type non-emptiable and stick to it for the new >> types? >> >> I like to hear your opinion. >
