7 ms·

There are two points which are worth bearing in mind: 1) There are RDBMS implementations which only conform to the standards when convenient and don't hesitate

There are two points which are worth bearing in mind: 1) There are RDBMS implementations which only conform to the standards when convenient and don't hesitate to deviate otherwise. This isn't to say that there is a standards only database (PostgreSQL has non-standard functionality, too), there isn't insofar as I know... but for many, standards compliance simply is not a goal. For PostgreSQL it is. 2) Especially with databases, longer term stability is often a more desirable trait than being fully up-to-date with every standards change. That doesn't mean that they shouldn't update at all/ever to take advantage of new standards defined behaviour, but it does suggest that the frequency of change in the database is going to be slower than the standards body producing versions. In neither case does this mean a "low bar" for the devs: in the first case it means they give a shit and that time doesn't somehow change how easy/hard it is to meet a standard; and in the second it means they are bringing some disciplined wisdom to the table.

avmich 9y ago
I'm sure there are RDB implementations less standard compliant than PostgreSQL. I'm just pointing out that we have SQL-2011 and SQL-2016, and for some other areas, like C++ implementations, standard conformance happens faster and closer to the standard. Saying "standard compliance is a goal for PostgreSQL" ought to mean efforts, and right now PostgreSQL can only show for those efforts the compliance to SQL-2008. Comparing to other areas - which is not apples to apples, I agree - looks quite humbling. For databases it's important to have long term stability, but same arguments apply elsewhere. For example, keeping non-standard behavior makes new projects - and I see those projects - to rely on them, which makes it again harder to get closer to the standard in the future. May be frequency of change is less in the RDB world, but it's still a problem when the changes are that infrequent, at least for some purposes. And yes, to do all that standard compliance is hard work for developers; yet for some reason we still have standard making process. It is hard, yes, but to keep behind by that much looks suspiciously similar to having a low bar. PostgreSQL shouldn't be too pride of itself in that aspect, even if they make more efforts and have better results than others.
- pgaddict 9y ago
  The main problem here is that the description you're referring to was not updated. That's not great, of course, but bashing PostgreSQL standards conformance merely based on a single high-level description is not cool either. Let me quote from the full documentation for PostgreSQL 9.6, released in September 2016, i.e. before SQL-2016 was published: > PostgreSQL supports most of the major features of SQL:2011. Out of 179 mandatory features required for full Core conformance, PostgreSQL conforms to at least 160. In addition, there is a long list of supported optional features. It might be worth noting that at the time of writing, no current version of any database management system claims full conformance to Core SQL:2011. For more details see: https://www.postgresql.org/docs/9.6/static/features.html https://www.postgresql.org/docs/9.6/static/features.html
  - sbuttgereit 9y ago
    Looks like my original response was wrong, too. > PostgreSQL development aims for conformance with the latest official version of the standard where such conformance does not contradict traditional features or common sense. Many of the features required by the SQL standard are supported, though sometimes with slightly differing syntax or function. Further moves towards conformance can be expected over time. Though I'll take refuge in the, "where such conformance does not contradict traditional features or common sense", clause ;-) .
    - avmich 9y ago
      > "where such conformance does not contradict traditional features or common sense" I'd prefer to have traditional features to move towards standard compliance - and to do have it as a priority - and also to have standards exhibiting the common sense which doesn't need to be questioned too much. Eventually it would be good I think to have DBMSes drop-in replaceable and until that goal isn't reached it's not good enough for some practical purposes. In this sense "sometimes with different syntax" reads surprising and "or function" is even more so. Did we all forget how and why SQL standards were created in the first place? How customers were demanding a certain level or interoperability? Do we think we don't need that anymore and the past reasons aren't there?

avmich 9y ago

I'm sure there are RDB implementations less standard compliant than PostgreSQL. I'm just pointing out that we have SQL-2011 and SQL-2016, and for some other areas, like C++ implementations, standard conformance happens faster and closer to the standard. Saying "standard compliance is a goal for PostgreSQL" ought to mean efforts, and right now PostgreSQL can only show for those efforts the compliance to SQL-2008. Comparing to other areas - which is not apples to apples, I agree - looks quite humbling. For databases it's important to have long term stability, but same arguments apply elsewhere. For example, keeping non-standard behavior makes new projects - and I see those projects - to rely on them, which makes it again harder to get closer to the standard in the future. May be frequency of change is less in the RDB world, but it's still a problem when the changes are that infrequent, at least for some purposes. And yes, to do all that standard compliance is hard work for developers; yet for some reason we still have standard making process. It is hard, yes, but to keep behind by that much looks suspiciously similar to having a low bar. PostgreSQL shouldn't be too pride of itself in that aspect, even if they make more efforts and have better results than others.

pgaddict 9y ago
The main problem here is that the description you're referring to was not updated. That's not great, of course, but bashing PostgreSQL standards conformance merely based on a single high-level description is not cool either. Let me quote from the full documentation for PostgreSQL 9.6, released in September 2016, i.e. before SQL-2016 was published: > PostgreSQL supports most of the major features of SQL:2011. Out of 179 mandatory features required for full Core conformance, PostgreSQL conforms to at least 160. In addition, there is a long list of supported optional features. It might be worth noting that at the time of writing, no current version of any database management system claims full conformance to Core SQL:2011. For more details see: https://www.postgresql.org/docs/9.6/static/features.html https://www.postgresql.org/docs/9.6/static/features.html
- sbuttgereit 9y ago
  Looks like my original response was wrong, too. > PostgreSQL development aims for conformance with the latest official version of the standard where such conformance does not contradict traditional features or common sense. Many of the features required by the SQL standard are supported, though sometimes with slightly differing syntax or function. Further moves towards conformance can be expected over time. Though I'll take refuge in the, "where such conformance does not contradict traditional features or common sense", clause ;-) .
  - avmich 9y ago
    > "where such conformance does not contradict traditional features or common sense" I'd prefer to have traditional features to move towards standard compliance - and to do have it as a priority - and also to have standards exhibiting the common sense which doesn't need to be questioned too much. Eventually it would be good I think to have DBMSes drop-in replaceable and until that goal isn't reached it's not good enough for some practical purposes. In this sense "sometimes with different syntax" reads surprising and "or function" is even more so. Did we all forget how and why SQL standards were created in the first place? How customers were demanding a certain level or interoperability? Do we think we don't need that anymore and the past reasons aren't there?