5 ms·
I'd rather have a solid codebase that's easy to maintain and has no quick hacks. Better take the time to do it correctly than having features that sometimes do
by silvestrov 13y ago
I'd rather have a solid codebase that's easy to maintain and has no quick hacks. Better take the time to do it correctly than having features that sometimes doesn't work.
PostgreSQL didn't become PostgreSQL by doing it the MySQL way.
- craigkerstiens 13y agoI'm definitely not advocating for rushing features in just for the sake of it, much of the reason for these missing was not due to poor implementations of them which is what makes it unfortunate.
- lucian1900 13y agoI would agree entirely, except perhaps about MERGE. I really wanted that. Unifying JSON and hstore can happen later, since its wouldn't necessarily enable new features, just make some things nicer.
- yeukhon 13y agoYeah. I see this will go on until 9.7, 9.8 before we can call things "really nice and stable" for JSON and HSTORE.
- redstripe 13y agoBut the crappy codebases already exist outside of postgres anytime people have to roll their own upsert implementation. The fact that it's hard is exactly why it should be in the database.
- cookiecaper 13y agoI don't think there's any contention at this point that it's a useful feature to have in the database. There just seems to be some disagreement on the finer points of the implementation. It'll get worked out, and Postgres will make it through another release with or without upsert.
- jeltz 13y agoIndeed, I followed the discussion and it was almost entirely about which implementation would best handle concurrency concerns.