Dynamic Typing in SQL
rockset.com
Dynamic Typing in SQL
1–10 of 27 posts
Re: Dynamic Typing in SQL
#2> Strong, because values have one specific type (or None)
Because its type system does not provide implicit type conversion I guess. But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract).
> Dynamic, because variables acquire type information at runtime, and the same variable can, at different points in time
This is not a characteristic of dynamic typing, some statically typed languages supports variable shadowing in the same scope. A dynamic (or hybrid) typing system is IMHO simply a system which provides a variant type as first class citizen.
Re: Dynamic Typing in SQL
#3It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
Re: Dynamic Typing in SQL
#4> Strong, because values have one specific type (or None) Because its type system does not provide implicit type conversion I guess. But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract). > Dynamic, because variables acquire type information at runtime, and the same variable can, at different points in time This is not a character…
> But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract).
Sure. Those are overly simplistic categories, but a full discussion of type systems in programming languages would be out of scope for that post.
> some statically typed languages supports variable shadowing in the same scope
Shadowing is a different issue. Shadowing refers to two different variables (which happens to have the same name), so it's orthogonal to whether the same variable is allowed to hold values of different types at different times.
Re: Dynamic Typing in SQL
#5It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
Even supposing this is an easier way to do without constraints, the effort to weaken static guarantees should be looked at askance. The great merit of Postgres' JSON types is that they can be used without losing strong data integrity guarantees.
Re: Dynamic Typing in SQL
#6It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
Even supposing this is an easier way to do without constraints, the effort to weaken static guarantees should be looked at askance. The great merit of Postgres' JSON types is that they can be used without losing strong data integrity guarantees.
Yes. In our case, though, Rockset is not a transactional database, but a query engine on top of existing data, so we're not the right place to enforce constraints anyway.
Re: Dynamic Typing in SQL
#7It would be helpful to see a side by side comparison with Postgres JSON schemas/queries.
That's on my TODO list, both in terms of performance and in terms of features / ease-of-use. (Another interesting thing to compare against is SQL++ (https://ci.apache.org/projects/asterixdb/sqlpp/manual.html) which has a couple of usability affordances that we might adopt.)
Re: Dynamic Typing in SQL
#8SQL types are actually default nullable, which puts them to the "not typed enough" category for my taste.
Re: Dynamic Typing in SQL
#9SQL types are actually default nullable, which puts them to the "not typed enough" category for my taste.
Then you really won't like it that we're moving in the opposite direction :)
I personally like strong, static type systems. But a lot of real world data doesn't match static schemas, which is why businesses hire data engineers to (build systems to) clean it up.
Re: Dynamic Typing in SQL
#10> Strong, because values have one specific type (or None) Because its type system does not provide implicit type conversion I guess. But some languages have a stronger type system with, in addition, highly qualified types (e.g. constness, range, sign or any custom contract). > Dynamic, because variables acquire type information at runtime, and the same variable can, at different points in time This is not a character…
[deleted]