There was a Slack thread at Redgate recently where a developer was showing some code where they decided to use the "extra" column from the information_schema.columns view. They were making decisions on how to detect certain metadata about a column based on the data in this column. Apparently, the data in here is overloaded for different options that might be set on a table.

This caught my eye because I had no idea there was a column named "extra" in this view. I flipped over to SSMS and decided to check what was being stored in here. To my surprise, there was no "extra" column. As I dug in a little deeper in the thread, I realized the developer was talking about Information_schema.columns in a MySQL database.

That was a surprise to me. While I know different platforms will add features and functionality to their databases, I thought the information_schema views were consistent across platforms. They should give you a set of information you can count on. Apparently, that's not true. You can count on some things, but not all, which means that these aren't consistent structures.

Perhaps it doesn't matter. It seems every product out there will extend the SQL "standard" where they see fit, adding features or functions that suit particular use cases. Commercial vendors do this for profit, and OSS projects likely do this because an individual wants a change. That has resulted in a wide variety of database platforms that meet different needs and solve different problems.

It would be nice if we could write SQL code and be sure it would run on SQL Server, Oracle, Snowflake, PostgreSQL, or any platform. And in many cases, we can. Lots of basic queries are the same. However, what would be the point? I certainly don't want more people in management wanting to switch from one platform to the other, just because they feel like it. I'd imagine that we'd thrash between platforms every time a senior developer or VP decided a system should run on their favorite platform.

A base standard is good, like a base class in programming. However, they aren't always as useful as they seem, and extending them to meet needs is better for us all. I don't need a standard implementation of the SQL language or the information_schema views, it was just a surprise to realize that this actually how the platforms are coded.