4 ms·

I'd still argue that at least you are aware there may be an issue with your code. So at least if something comes up (duplicates, exceptions during high load ups

I'd still argue that at least you are aware there may be an issue with your code. So at least if something comes up (duplicates, exceptions during high load upserts) you'll know where to look.

ris 13y ago
And at least the version he's using will likely retain the subtleties of its behaviour over future postgres versions. Depending on a "shitty & broken" implementation that goes into postgres which then subtly changes its behaviour after a few years could cause no end of problems.
jonrimmer 13y ago
Will you remember though, six months later? What about when someone inherits the codebase from you, or you inherit a codebase from someone else containing a solution someone else implemented? You'll be stuck trying to diagnose and fix issues with very little guidance, because only a handful of other people may have implemented the same solution as you. Having a single, canonical solution, even if it it's imperfect, is usually better than having a myriad of equally imperfect options. At least then documentation and community guidance can coalesce around it. Its caveats can be properly explored and explained, and when you do run into trouble and go looking for help, you're far more likely to find people who have had the same problems in the past. Saying "feature x is hard, so we'll leave it to developers to figure out" is a disastrous mindset for any piece of software. The whole point of frameworks, runtime libraries, DBs, etc. is to provide developers with standardised, battle-tested infrastructure to do difficult things that require specialist knowledge outside of their area of expertise to get right. The argument that the hardest stuff should be left out, because it encourages developers to try and figure it out themselves is crazy: if the PostgreSQL developers can't work out how to implement upsert perfectly, then non-DB specialists are likely to do even worse.
- chrisfarms 13y ago
  I certainly wasn't saying the feature should not exist because it's hard.... merely, do it right or not at all. The culture on the Postgres development side has always taken a very conservative approach, which carries with it much trust that the features that exist work very well. Introducing a half-baked feature would break this trust. And so I would rather wait.
  - spacemanmatt 13y ago
    +1 When you have a huge investment in your data, a conservative approach to database servers is full of merit. Once I began to understand concurrent design my years of MySQL experience were suddenly curdled. I had to switch to a server/community that care about integrity, and do not play fast and loose with new features. It's not a popularity contest.
  - nuclear_eclipse 13y ago
    I would rather see a single, well-defined and correct implementation, even if it's really slow, than to not have it at all...

I'd still argue that at least you are aware there may be an issue with your code. So at least if something comes up (duplicates, exceptions during high load upserts) you'll know where to look.

ris 13y ago

And at least the version he's using will likely retain the subtleties of its behaviour over future postgres versions. Depending on a "shitty & broken" implementation that goes into postgres which then subtly changes its behaviour after a few years could cause no end of problems.

jonrimmer 13y ago

Will you remember though, six months later? What about when someone inherits the codebase from you, or you inherit a codebase from someone else containing a solution someone else implemented? You'll be stuck trying to diagnose and fix issues with very little guidance, because only a handful of other people may have implemented the same solution as you. Having a single, canonical solution, even if it it's imperfect, is usually better than having a myriad of equally imperfect options. At least then documentation and community guidance can coalesce around it. Its caveats can be properly explored and explained, and when you do run into trouble and go looking for help, you're far more likely to find people who have had the same problems in the past. Saying "feature x is hard, so we'll leave it to developers to figure out" is a disastrous mindset for any piece of software. The whole point of frameworks, runtime libraries, DBs, etc. is to provide developers with standardised, battle-tested infrastructure to do difficult things that require specialist knowledge outside of their area of expertise to get right. The argument that the hardest stuff should be left out, because it encourages developers to try and figure it out themselves is crazy: if the PostgreSQL developers can't work out how to implement upsert perfectly, then non-DB specialists are likely to do even worse.

chrisfarms 13y ago
I certainly wasn't saying the feature should not exist because it's hard.... merely, do it right or not at all. The culture on the Postgres development side has always taken a very conservative approach, which carries with it much trust that the features that exist work very well. Introducing a half-baked feature would break this trust. And so I would rather wait.
- spacemanmatt 13y ago
  +1 When you have a huge investment in your data, a conservative approach to database servers is full of merit. Once I began to understand concurrent design my years of MySQL experience were suddenly curdled. I had to switch to a server/community that care about integrity, and do not play fast and loose with new features. It's not a popularity contest.
- nuclear_eclipse 13y ago
  I would rather see a single, well-defined and correct implementation, even if it's really slow, than to not have it at all...