Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



But 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.


I 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.


Indeed, I followed the discussion and it was almost entirely about which implementation would best handle concurrency concerns.


I'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.


I 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.


Yeah. I see this will go on until 9.7, 9.8 before we can call things "really nice and stable" for JSON and HSTORE.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: