I want to give a giant digital hug to all PG committers who made this happen.
Postgres gets support for upsert
31–40 of 114 posts
Re: Postgres gets support for upsert
#32I think I squealed with delight when I read this title. This is really a great addition, and will simplify so much of my code once I'm able to upgrade. I try not to think too deeply about all the DB internals (some people are much smarter than me about this stuff), but clearly there are a lot of things that need maintained internally to make this correct, so kudos to all the people who contributed to this.
A big +1 to this. Peter Geoghegan is the primary author and has been championing it for over 2 Postgres releases now. I know he's especially excited to see it land.
Also it couldn't have been possible without the support of Heikki and Andres (who actually submitted this to HN as his first ever submission).
Re: Postgres gets support for upsert
#33Earlier quoted context omitted.
Because the devs pay attention, and take the time to do things right. See https://wiki.postgresql.org/wiki/UPSERT for a glimpse into the design that needed to go behind this. I feel a lot of Postgres fans (myself included) put their "money" on Postgres circa late version 7 or early version 8, back when MySQL was the more featureful and performant of the two, while Postgres had the reputation for being more, shall we…
> late version 7 or early version 8, back when MySQL was the more featureful and performant of the two MySQL was never more featureful. The reason I started migrating back in the 7.1 time frame (when TOAST tables were added and you could finally store more than 8K of text in a TEXT column) was the lack of sub-selects in MySQL. Even aside of that, Postgres was far ahead when considering basic SQL support: stored proce…
MariaDB, WebScaleSQL, Percona are just three MySQL forks that are completely open source in every single way. Likewise MySQL-Server is GPL so it definitely should be considered as open source.
And if MySQL wasn't robust then YouTube, Facebook, Twitter, Alibaba, LinkedIn etc wouldn't be using it for core parts of their infrastructure. It's definitely robust.
No doubt that PostgreSQL is better at MySQL in many areas though and probably could do with a self contained, single download PostgreSQL Cluster edition.
Re: Postgres gets support for upsert
#34I think I squealed with delight when I read this title. This is really a great addition, and will simplify so much of my code once I'm able to upgrade. I try not to think too deeply about all the DB internals (some people are much smarter than me about this stuff), but clearly there are a lot of things that need maintained internally to make this correct, so kudos to all the people who contributed to this.
A big +1 to this. Peter Geoghegan is the primary author and has been championing it for over 2 Postgres releases now. I know he's especially excited to see it land. Also it couldn't have been possible without the support of Heikki and Andres (who actually submitted this to HN as his first ever submission).
Hah, where from do you know that I don't have my sock puppet accounts ;)
Re: Postgres gets support for upsert
#35[deleted]
Re: Postgres gets support for upsert
#36Damnit, I just wrote a sweet gem that handles this... ah, okay, but it requires an index constraint, whereas I needed to merge on arbitrary conditions. So I didn't totally waste my time.
Way to go Postgres team!
Re: Postgres gets support for upsert
#37I know it doesn't matter to some developers out there, but for me, the only thing left is the ability to add a column after another one. Even if it's only logical order, it's easier for me to read a table structure when fields are ordered nicely.
Re: Postgres gets support for upsert
#38I know it doesn't matter to some developers out there, but for me, the only thing left is the ability to add a column after another one. Even if it's only logical order, it's easier for me to read a table structure when fields are ordered nicely.
Unsure what you mean. A subset of columns can be selected in any order, across tables. Were you referring to the select order used by "*"?
Re: Postgres gets support for upsert
#39I know it doesn't matter to some developers out there, but for me, the only thing left is the ability to add a column after another one. Even if it's only logical order, it's easier for me to read a table structure when fields are ordered nicely.
Unsure what you mean. A subset of columns can be selected in any order, across tables. Were you referring to the select order used by "*"?
Re: Postgres gets support for upsert
#40I know it doesn't matter to some developers out there, but for me, the only thing left is the ability to add a column after another one. Even if it's only logical order, it's easier for me to read a table structure when fields are ordered nicely.
Unsure what you mean. A subset of columns can be selected in any order, across tables. Were you referring to the select order used by "*"?
Yes, I think it's about changing the default presentation order. That could be a feature of the client, psql, pgcli, pgadmin3, but it won't be portable across them unless it's some metadata stored inside the db. Is there any db with that feature?
Edit: munro answered that. PostgreSQL does it but it's expensive because it has to rewrite the table.