> 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'm with Benedict. Seems like this could help prevent whatever "nulls in primary key columns" problems Aleksey was alluding to on those tickets back in the day that pushed us towards making the new types non-emptiable as well (i.e. primary keys are non-null in table definition).
Furthering Alex' question, having a default value for unset fields in any non-collection context seems... quite surprising to me in a database. I could see the argument for making container / collection types non-nullable, maybe, but that just keeps us in a potential straddle case (some types nullable, some not). On Tue, Sep 19, 2023, at 8:22 AM, Benedict wrote: > > 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. >>
