Information Schema Strangeness

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.

Note: If you find this interesting, I had a discussion recently with a few others in a webinar.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

2 Responses to Information Schema Strangeness

  1. Russ Loski says:

    I am ok with different vendors extending standard objects as long as they document the differences. For example I would find it useful for Microsoft to include an object id column in the Information Schema views. However, the columns should be at the end of the list of columns and Microsoft should make it very clear that this is an extension.


  2. way0utwest says:

    Agree. In the docs, this ought to say “not ANSI standard”.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.