Primary key error in INFORMATION_SCHEMA views

On Thursday, May 24, 2018, SQLpro <sqlpro(at)sqlspot(dot)com> wrote:

> Hi Tom,
>
> For a DBMS which loudly proclaims to be the most respectful of the SQL
> standard, not being able to use the INFORMATION_SCHEMA views because of
> such
> an error seems to me to go against its philosophy.
>
> Can not you change that by adding a configuration parameter, for a future
> version, that would allow you to apply these views more strictly?
>
> More pragmatically, what good can these views serve if we can not use them
> properly without bug? Better to remove them if you choose not to fix this
> bug …
>

Views don't have primary keys, they just report what is already stored. If
the database is standard conforming the view works perfectly. It also works
just fine if you accept that table name is part of the uniqueness so it
does provide useful and accurate data even though we don't conform to the
standard in this way. And breaking working applications to meet standard
conformance here is a losing cause.

Even with an option it would default to false and nearly everyone would
leave it that way. Those that would change it to true can easily write a
validation script of their own to check for duplicates that need fixing.

For better and worse this is what we have. Standard conformance is
respected but we are not going to cut off our own for just to meet a
marginal requirement that we don't actual prevent people from choosing to
adhere to themselves.

You haven't actually described the problem you are running into so further
insights that could alleviate your confusion are not possible.

David J.