3 ms·

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 are

• 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?
      • pgaddict 9y ago
        Your preferences are one thing, your patches or having a say into the development is a very different thing. The standards conformance is not a goal on it's own. The primary goal of the developers is to serve the users, particularly those that support the community in some way (e.g. by paying the developers). That's what makes the project possible. Development of features takes time, and the features are often introduced years before SQL standard eventually codifies them. And Postgres community has pretty much no influence on the SQL Standard, which is driven mainly by large companies. The last thing the users want is having to do significant changes to their applications just before the syntax suddenly changed to match SQL standard. Standards are valuable, but backwards compatibility has a value too. > 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? The SQL standard was created so that each database did not invent it's own query language. Postgres had one (called QUEL), and abandoned it in favor of SQL in 95 or so. Because people wanted the same general API to databases, not because they wanted the databases to behave the same. I strongly disagree with the idea that databases should be drop-in replaceable, as it entirely ignores the large parts of the fuctionality (architecture, indexing, ...) which is out of scope of a SQL standard.
        • avmich 9y ago
  • avmich 9y ago
    I think the reason why standards are created is to be able to choose among various implementations on the basis of something other than what is the set of technical features. In this manner one can choose performance, convenience of licensing or something else and not to worry about will his program work the same or work at all with different DB engine. If we don't have standard compliance, this becomes that much harder. Now engineers and whole companies have to choose in advance what to base their systems on, and evolve further often with keeping that constraint for the whole project lifetime. More, different DBMS vendors feel the ability to market some features while paying less attention to standard compliance, which leads to bigger incompatibilities between DBMSes. So the whole point of having standards in the first place gets eroded. In this light both mentioning a long list of supported features and pointing that other databases do no better is a poor substitute to leading the industry in standard compliance and all associated benefits. I think PostgreSQL can do better.