Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 10 Beta 1 Released

postgresql.org

Post reply on HN
Print view View original

141–150 of 172 posts

Re: PostgreSQL 10 Beta 1 Released

#141

Post by _Codemonkeyism »

jph wrote: post #3

Congratulations to the team. The replication/partition improvements are significant and much appreciated. My favorite improvements are full text search of JSON & JSONB; this makes pg a full replacement for Mongo for my use cases.

Using MySQL/Mongo for some years, major problems with MongoDB Cloud Manager (several hours site down due to Cloud Manager removing the mongo binary), for some time now I use pg for new projects and think it's great.

Two gripes:

1. Client libraries in Mongo work nicer with documents than Postgres libraries with JSONB (e.g. Scala Option[] mapping to non existing/existing fields)

2. Why is the Postgres JSON syntax so different? Why not just support SELECT document.field.field instead of (inconsistent) document->'field'. Imho pg JSON syntax is hard to read and new to learn.

Re: PostgreSQL 10 Beta 1 Released

#142

Post by luhn »

_Codemonkeyism wrote: post #141
jph wrote: post #3

Congratulations to the team. The replication/partition improvements are significant and much appreciated. My favorite improvements are full text search of JSON & JSONB; this makes pg a full replacement for Mongo for my use cases.

Using MySQL/Mongo for some years, major problems with MongoDB Cloud Manager (several hours site down due to Cloud Manager removing the mongo binary), for some time now I use pg for new projects and think it's great. Two gripes: 1. Client libraries in Mongo work nicer with documents than Postgres libraries with JSONB (e.g. Scala Option[] mapping to non existing/existing fields) 2. Why is the Postgres JSON syntax so di…

Re 2: That syntax is already in use by `SELECT schema.column`. I do agree that the syntax is a bit cumbersome and harder to learn, but I'm not sure if they could have done much better while being consistent with SQL.

Re: PostgreSQL 10 Beta 1 Released

#143

Post by manigandham »

threeseed wrote: post #92
gshulegaard wrote: post #75

Earlier quoted context omitted.

I would say that it isn't configured to scale like Mongo out of the box...but that doesn't mean it can't. You can go outside of Postgres core to get multi-master solutions with easy sharding and clustering...with the open sourcing of CitusDB and 2nd Quadrant's pglogical and BDR extensions there are options out there. You can also roll your own (if you really want)...and it is relatively approachable to do so using bu…

None of what you posted is built in and thus supported by the vendor. That may not matter to you but it's a deal breaker for those of us in enterprises. We can't just be rolling our own versions of PostgreSQL and we can't use CitusDB when it is not supported by other vendors for use with their products. The point still remains that after all these year PostgreSQL's scalability story is still a mess.

> PostgreSQL's scalability story is still a mess

This is absolutely true. I don't get the irrational downvotes when it comes to postgres.

It's a great database but it is sorely behind with scalability features and is just now finally getting single-node parallelism and logical replication. It's still hampered by the requirement on 3rd party tools to get connection scaling, decent backups, HA and distributed clustering. The future looks interesting but the other databases aren't sitting around idly either.

Re: PostgreSQL 10 Beta 1 Released

#144

Post by rimliu »

jdubs wrote: post #12
alfalfasprout wrote: post #5

The native table partitioning makes me so happy. I'd been doing this for years with really hacky external modules and tons of triggers. Sadly, even then there were always weird edge cases. Postgres really has become the most versatile database out there. I cringe whenever I have to work with MySQL again...

Every time I see a job post mentioning mysql I realize they just haven't discovered postgres, or they have some really gross problem. :/

That's very condescending of you. They may be just well informed of their use cases and know which database fits them well. Poor Wikipedia and FB with their MySQL setups, they have no idea how much better of they'd be with postgres…

Re: PostgreSQL 10 Beta 1 Released

#145

Post by rimliu »

combatentropy wrote: post #132
grzm wrote: post #129

Earlier quoted context omitted.

In general, strive for substantive and constructive comments on HN. If you've got that, a little humor added in can be appreciated. Comments that are submitted only for humor value (which you knew yours was, given your parenthetical addendum) are likely to be less appreciated on HN than on other sites. Here's a recent thread where this has been discussed: https://news.ycombinator.com/item?id=13760333 There are likely…

So what I want to know is how the members of Hacker News act as one. Presumably these are the same people who appreciate humor on other sites, upvote it, and participate in it. But on Hacker News they somehow all know to downvote it. It's eerie.

It's rather sad what set of behaviour is considered "professional".

Re: PostgreSQL 10 Beta 1 Released

#146

Post by Twisell »

walrus wrote: post #56
pilif wrote: post #13

While everybody is going to be rightfully excited about the logical replication, for me personally, CREATE STATISTICS and the new ROW syntax for UPDATE amount to the additions that have the probably biggest effect on me ever since I moved to postgres exclusively when 7.1 was released. Especially CREATE STATISTICS (wonderful explanation here https://www.postgresql.org/docs/10.0/static/multivariate-sta... ) is the one…

What's the significance of the `update .. set (..) = row (..) ..` syntax? update comment set modified = now(), body = 'edited comment' where id = 123; vs update comment set (modified, body) = row (now(), 'edited comment') where id = 123; It doesn't seem to provide any new functionality, just a minor difference in syntax.

I think it might also simplify the syntax if you want to update multiple columms from a composite type (which is essentially a ROW) so that writing sub query is not needed anymore.

Re: PostgreSQL 10 Beta 1 Released

#147

Post by flukus »

snuxoll wrote: post #41

I know this sounds icky to some, but what I really want from Postgres is a proper equivalent to MSSQL's FILESTREAM. I know, I know, "databases are bad for files" - but let's take something like an ECM suite where images and documents are literally part of a transaction, having to synchronize those between filesystem and database breaks the Atomic constraint in so many ways. PostgreSQL has LOB support, but oid's being…

Is there an OSS version of DTC (Distributed transaction coordinator)? That gives you the transactionality you want from the file system and other systems.

Re: PostgreSQL 10 Beta 1 Released

#148

Post by wmu »

_jal wrote: post #33
ilanco wrote: post #24

PostgreSQL is an amazing project. A no-nonsense database that delivers what it promises. I'm amazed at what a talented group of people can accomplish when they are driven and put their mind to it. Thanks for a wonderful product.

Absolutely agreed. A friend of mine was doing an MBA and was planning a paper on open source collaboration models. She asked me for my opinion on well-run projects and Postgres was the first thing that crossed my mind. They have an excellent combination of goals, structure and expertise, and have created a remarkably low-drama, functional community around delivering excellent tools. I really think there's a lot to em…

My short story regarding community. A few years ago I wanted to add a feature to PL/pgSQL that was on their TODO list. I asked about the feature on a public list and while I was unknown to the community I immediately got a private email from a developer who contributed to that part of code. We discussed the required changes and I prepared a patch. He reviewed it and later was supporting during formal review.

Re: PostgreSQL 10 Beta 1 Released

#149

Post by olavgg »

rarrrrrr wrote: post #21
ubertaco wrote: post #14

Earlier quoted context omitted.

Or they want to allow for case-insensitivity of some data, like for example email addresses on login forms. As much as postgres is overall better than MySQL in so many ways, it's still ridiculously difficult to set things up such that SELECT id FROM users WHERE email='foo@example.com' returns the same result as SELECT id FROM users WHERE email='Foo@example.com'

Here's an example of doing that in PostgreSQL: create table user_email ( email text not null ); -- create a index on the lowercase form -- of the email create unique index user_email_case_idx on user_email (lower(email)); -- select using the index, with the lowercase form. select 1 from user_email where lower(email)=lower('Foo@foo.com');

actually it is easier

SELECT 1 FROM user_email WHERE email ILIKE 'Foo@Foo.coM';

Post reply on HN