3 ms·

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 ow

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
> Your preferences are one thing, your patches or having a say into the development is a very different thing. That's correct; "saying", as I do, and "having a say" are different. In practice however my options as a user of DBMS are limited - I don't know if I can buy a standard compliant DBMS at all, not to say for market-competitive price, and I'm not sure I'll have an opportunity to replace it with another standard compliant implementation if for some reasons I'll want to have a better match. In other words, I'm market taker, and not market maker. I do suspect there are many DB users in this same position, which would benefit from a possibility to switch from DBMS to DBMS. > 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. It would be nice if developers of a leading open source DBMS paid more attention to standards - that's what I'm saying. I don't believe their users would suffer from that, or even that their users are sufficiently indifferent to that - that's neither my own experience nor what I'm reading in articles touching choices of DB. > 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. I understand this as you saying "we have a choice between features and standards, and we choose features". Yes, backwards compatibility has value; in my opinion, value of standard following isn't understood well enough. I think we aren't in the world where performance is uber important for all use cases; those involved in development of PostgreSQL are either not fully aware of the needs of - some, may be non-paying - users, or choose to postpone this work, that's my understanding of the situation. > The SQL standard was created so that each database did not invent it's own query language. Exactly. Same language means that if I have, say, window functions or isolation levels in SQL standard and use them, I can expect to have them and them to be functionally equivalent in standard compliant implementation. It's a sad situation when there are just a few, if any, implementations of the standard; why do we have standards in the first place become then questionable. > 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. As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you could have extension features on top of standard, allowing users to use them when they choose to have extensions or not to use them when they need to have conformance to standards. I've had discussions regarding DB choice based on features which are in non-implemented standards enough to pay attention to the matter.
- pgaddict 9y ago
  > As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you could have extension features on top of standard, allowing users to use them when they choose to have extensions or not to use them when they need to have conformance to standards. I've had discussions regarding DB choice based on features which are in non-implemented standards enough to pay attention to the matter. No. I'm saying that the SQL Standard deals only with the querying language. It does not cover a million other aspects of database engines, that determine how well the databases are suited for different use cases (performance, tolerance to failures, single-node vs. distributed, OLTP vs. analytics). Those are the differences that make treating databases as drop-in replaceable naive - even if the databases were 100% compatible at the SQL level, you can't really replace them easily because the query language is just a tip of the iceberg.
  - avmich 9y ago
    To me, drop-in replacement means the interface is the same, not implementation. You can have list operations on top of array, single or double linked lists etc., and you'll get different Big O numbers for different operations, different memory access patterns - but will still have the same append() and length() functions in the API. Drop-in doesn't mean "equivalent in all measurable aspects". I spend substantial time navigating and compensating for differences in DB interfaces - not characteristics of internal solutions. Standards aren't about that - they are, as I understand, to solve the problem which I have, because standards aren't followed. I want to be able to replace databases not because they are the same - what would be the purpose then - but because having the same interface (i.e., the ability to just replace the DBMS) they could provide me a choice of characteristics.

avmich 9y ago

> Your preferences are one thing, your patches or having a say into the development is a very different thing. That's correct; "saying", as I do, and "having a say" are different. In practice however my options as a user of DBMS are limited - I don't know if I can buy a standard compliant DBMS at all, not to say for market-competitive price, and I'm not sure I'll have an opportunity to replace it with another standard compliant implementation if for some reasons I'll want to have a better match. In other words, I'm market taker, and not market maker. I do suspect there are many DB users in this same position, which would benefit from a possibility to switch from DBMS to DBMS. > 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. It would be nice if developers of a leading open source DBMS paid more attention to standards - that's what I'm saying. I don't believe their users would suffer from that, or even that their users are sufficiently indifferent to that - that's neither my own experience nor what I'm reading in articles touching choices of DB. > 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. I understand this as you saying "we have a choice between features and standards, and we choose features". Yes, backwards compatibility has value; in my opinion, value of standard following isn't understood well enough. I think we aren't in the world where performance is uber important for all use cases; those involved in development of PostgreSQL are either not fully aware of the needs of - some, may be non-paying - users, or choose to postpone this work, that's my understanding of the situation. > The SQL standard was created so that each database did not invent it's own query language. Exactly. Same language means that if I have, say, window functions or isolation levels in SQL standard and use them, I can expect to have them and them to be functionally equivalent in standard compliant implementation. It's a sad situation when there are just a few, if any, implementations of the standard; why do we have standards in the first place become then questionable. > 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. As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you could have extension features on top of standard, allowing users to use them when they choose to have extensions or not to use them when they need to have conformance to standards. I've had discussions regarding DB choice based on features which are in non-implemented standards enough to pay attention to the matter.

pgaddict 9y ago
> As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you could have extension features on top of standard, allowing users to use them when they choose to have extensions or not to use them when they need to have conformance to standards. I've had discussions regarding DB choice based on features which are in non-implemented standards enough to pay attention to the matter. No. I'm saying that the SQL Standard deals only with the querying language. It does not cover a million other aspects of database engines, that determine how well the databases are suited for different use cases (performance, tolerance to failures, single-node vs. distributed, OLTP vs. analytics). Those are the differences that make treating databases as drop-in replaceable naive - even if the databases were 100% compatible at the SQL level, you can't really replace them easily because the query language is just a tip of the iceberg.
- avmich 9y ago
  To me, drop-in replacement means the interface is the same, not implementation. You can have list operations on top of array, single or double linked lists etc., and you'll get different Big O numbers for different operations, different memory access patterns - but will still have the same append() and length() functions in the API. Drop-in doesn't mean "equivalent in all measurable aspects". I spend substantial time navigating and compensating for differences in DB interfaces - not characteristics of internal solutions. Standards aren't about that - they are, as I understand, to solve the problem which I have, because standards aren't followed. I want to be able to replace databases not because they are the same - what would be the purpose then - but because having the same interface (i.e., the ability to just replace the DBMS) they could provide me a choice of characteristics.