4 ms·

Looks like my original response was wrong, too. > PostgreSQL development aims for conformance with the latest official version of the standard where such confo

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
    > 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.
- sbuttgereit 9y ago
  > 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? So, since you wrote here originally in part to complain about the low bar PostgreSQL set for themselves in trying to be standards compliant to an old standard (which has now been shown to merely be due to a stale document)... just who, in your view, should the good folks on the PostgreSQL dev team look to for how it's done? Which RDBMS provider/vendor has set the bar high for themselves in regard to standards compliance and achieved it?
  - avmich 9y ago
    I'm not particularly familiar with how PostgreSQL development is done. I suspect it carries a lot of baggage from the past releases, both good and bad. I hope the team will see the value in structuring the product in such a way that users of the product won't feel themselves making a hard choice taking PostgreSQL for new projects - or maintaining it in existing systems. > Which RDBMS provider/vendor has set the bar high for themselves in regard to standards compliance and achieved it? I think we had better compliance to the standards in DB industry as a whole some years ago, but that's just a feeling. I think we have right now better compliance to the standards - as in industry mostly following standards within, say, 5 years - in branches of engineering like compilers and browsers. In open source SQL engines PostgreSQL is overall one of the strongest propositions which I recommend often. However you don't maintain your lead if you don't recognize your weak points.
pgaddict 9y ago
I don't see why would that make the original response wrong?
- sbuttgereit 9y ago
  It's not entirely wrong to be sure. But the case I was laying out was, in part, predicated on the PostgreSQL devs taking a more conservative approach top standards compliance than they actually are (per that sentence about their goals relative to standards compliance). So in that regard I was wrong. That's not to say the devs are being reckless about it either, which they've made clear in their noting exceptions to that goal.

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
  > 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.
sbuttgereit 9y ago
> 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? So, since you wrote here originally in part to complain about the low bar PostgreSQL set for themselves in trying to be standards compliant to an old standard (which has now been shown to merely be due to a stale document)... just who, in your view, should the good folks on the PostgreSQL dev team look to for how it's done? Which RDBMS provider/vendor has set the bar high for themselves in regard to standards compliance and achieved it?
- avmich 9y ago
  I'm not particularly familiar with how PostgreSQL development is done. I suspect it carries a lot of baggage from the past releases, both good and bad. I hope the team will see the value in structuring the product in such a way that users of the product won't feel themselves making a hard choice taking PostgreSQL for new projects - or maintaining it in existing systems. > Which RDBMS provider/vendor has set the bar high for themselves in regard to standards compliance and achieved it? I think we had better compliance to the standards in DB industry as a whole some years ago, but that's just a feeling. I think we have right now better compliance to the standards - as in industry mostly following standards within, say, 5 years - in branches of engineering like compilers and browsers. In open source SQL engines PostgreSQL is overall one of the strongest propositions which I recommend often. However you don't maintain your lead if you don't recognize your weak points.

pgaddict 9y ago

I don't see why would that make the original response wrong?

sbuttgereit 9y ago
It's not entirely wrong to be sure. But the case I was laying out was, in part, predicated on the PostgreSQL devs taking a more conservative approach top standards compliance than they actually are (per that sentence about their goals relative to standards compliance). So in that regard I was wrong. That's not to say the devs are being reckless about it either, which they've made clear in their noting exceptions to that goal.