4 ms·

> I mean I guess it's a cute bit of syntactic sugar but are you really going to die if you have to manually specify the columns you want? That's a vastly safer/

> I mean I guess it's a cute bit of syntactic sugar but are you really going to die if you have to manually specify the columns you want? That's a vastly safer/less brittle practice. No, it's a basic piece of functionality that should have existed a long time ago. I'm reminded of a quote, I think from pg that goes like "programming languages teach you to not want what they can't give you." It's absolutely true. I see few language features met with comments like yours and I just wonder, why? Why can a feature only be added if the alternative is that we're "going to die?" As somebody who does SQL for a majority of their work, this feature is so overdue. I briefly used RethinkDB from 2013-2014 and RQL supported this functionality. What a treat it would be to be able to do this on Postgres.

city41 8y ago
I'm in the opposite camp. Even small features are very expensive. You need to support them for the life of the product. You need to think about them every time a new feature, bug fix, anything comes along. I prefer products that have smaller feature sets and those features are rock solid and very well thought out than just throwing every possibility in because you can. If skipping EXCEPT means say the postgres team can focus that much more energy on bugs and stability, then that's a good trade off in my eyes.
- slap_shot 8y ago
  Except that's not how real software is built. Real software has to add new features to remain competitive. Just look at a few of the features for Postgres 9.4 to 10: JSONB data type, ALTER SYSTEM statement for changing config values, ability to refresh materialized views without blocking reads, dynamic registration/start/stop of background worker processes, Logical Decoding API, GiN index improvements, Linux huge page support, database cache reloading via pg_prewarm UPSERT, row level security, TABLESAMPLE, CUBE/ROLLUP, GROUPING SETS, and new BRIN index[113] Parallel query support, PostgreSQL foreign data wrapper (FDW) improvements with sort/join pushdown, multiple synchronous standbys, faster vacuuming of large table Logical replication, declarative table partitioning, improved query parallelism We'd all love for software to be bug-free and stable, but features have to be added.
  - RussianCow 8y ago
    Nobody is arguing that products shouldn't have features. But there is a real cost to each feature that you add, and so you have to weigh the tradeoffs before blindly building everything anyone asks for. Selecting all columns but one seems like it would bring much less value than JSONB.
    - slap_shot 8y ago
      The parent comment said he preferred software with less features, and favored bug fixing and stability over feature X. Feature X could be swapped with any request in Postgres's backlog. I agree with you: all features have to have a cost and value. The market decides what features are valuable, and they get built and supported. SELECT EXCEPT is not one that the market values yet. And that's fine.
      - mmt 8y ago
        > The market decides what features are valuable, and they get built and supported. I'm curious as to what you envision as "the market" in the context of free software, or Postgres in particular, since I don't expect it's the cliche of people literally deciding which product to pay for among competing ones. A couple possibilities came to mind, but, having no intimate familiarity with any major project like this, I didn't want to parade mere assumptions as multiple choice.
  - city41 8y ago
    For sure, that is the reality we live in. Doesn’t mean it’s a good thing though. There’s even been some push back to this trend, such as Apple reconsidering how they do release cycles due to iOS becoming so buggy. It also depends on what kind of software we are talking about. A trendy mobile app is very different from a critical database. I personally prefer software that’s more conservative in its approach to new features. It’s becoming harder to find software that has this philosophy but not yet impossible.
paulmd 8y ago
What happens if you ALTER TABLE ADD COLUMNs? The fact that you can add Oracle triggers that fail after the fact is one of the things I hate most. Adding columns can break EXCEPT queries. This is one of those situations where adding a feature can break a lot of other stuff after the fact.
- asah 8y ago
  That house left the barn with SELECT *, which is sensitive to the addition of new columns.

city41 8y ago

I'm in the opposite camp. Even small features are very expensive. You need to support them for the life of the product. You need to think about them every time a new feature, bug fix, anything comes along. I prefer products that have smaller feature sets and those features are rock solid and very well thought out than just throwing every possibility in because you can. If skipping EXCEPT means say the postgres team can focus that much more energy on bugs and stability, then that's a good trade off in my eyes.

slap_shot 8y ago
Except that's not how real software is built. Real software has to add new features to remain competitive. Just look at a few of the features for Postgres 9.4 to 10: JSONB data type, ALTER SYSTEM statement for changing config values, ability to refresh materialized views without blocking reads, dynamic registration/start/stop of background worker processes, Logical Decoding API, GiN index improvements, Linux huge page support, database cache reloading via pg_prewarm UPSERT, row level security, TABLESAMPLE, CUBE/ROLLUP, GROUPING SETS, and new BRIN index[113] Parallel query support, PostgreSQL foreign data wrapper (FDW) improvements with sort/join pushdown, multiple synchronous standbys, faster vacuuming of large table Logical replication, declarative table partitioning, improved query parallelism We'd all love for software to be bug-free and stable, but features have to be added.
- RussianCow 8y ago
  Nobody is arguing that products shouldn't have features. But there is a real cost to each feature that you add, and so you have to weigh the tradeoffs before blindly building everything anyone asks for. Selecting all columns but one seems like it would bring much less value than JSONB.
  - slap_shot 8y ago
    The parent comment said he preferred software with less features, and favored bug fixing and stability over feature X. Feature X could be swapped with any request in Postgres's backlog. I agree with you: all features have to have a cost and value. The market decides what features are valuable, and they get built and supported. SELECT EXCEPT is not one that the market values yet. And that's fine.
    - mmt 8y ago
      > The market decides what features are valuable, and they get built and supported. I'm curious as to what you envision as "the market" in the context of free software, or Postgres in particular, since I don't expect it's the cliche of people literally deciding which product to pay for among competing ones. A couple possibilities came to mind, but, having no intimate familiarity with any major project like this, I didn't want to parade mere assumptions as multiple choice.
- city41 8y ago
  For sure, that is the reality we live in. Doesn’t mean it’s a good thing though. There’s even been some push back to this trend, such as Apple reconsidering how they do release cycles due to iOS becoming so buggy. It also depends on what kind of software we are talking about. A trendy mobile app is very different from a critical database. I personally prefer software that’s more conservative in its approach to new features. It’s becoming harder to find software that has this philosophy but not yet impossible.

paulmd 8y ago

What happens if you ALTER TABLE ADD COLUMNs? The fact that you can add Oracle triggers that fail after the fact is one of the things I hate most. Adding columns can break EXCEPT queries. This is one of those situations where adding a feature can break a lot of other stuff after the fact.

asah 8y ago
That house left the barn with SELECT *, which is sensitive to the addition of new columns.