PostgreSQL 10 Beta 1 Released

Post by jerrysievert » Thu, May 18, 2017, 5:53 PM UTC

fnayr wrote: post #49

ssijak wrote: post #42

Earlier quoted context omitted.

But the posters above you said that JSON and JSONB types in Postgres, and functionality around them, eliminated the need to use other databases for document type data. What you are describing can be done with PostgreSQL. One thing that is missing is better client libraries that make use of those data types. Morphia wins for now in that regard.

My claim wasn't that it didn't fulfill their needs, it was that it doesn't fulfill all needs (gamedev is one example that I'm familiar with). Postgres storing JSON types != All mongo functionality I'm sure I could achieve everything I'm doing in mongo by some roundabout way in Postgres, but if you're doing a large amount of reading/modifying partial fields within JSON structure, it's the exact use case for mongo.

Post by pkhagah » Thu, May 18, 2017, 6:07 PM UTC

byefruit wrote: post #20

htsh wrote: post #16

Earlier quoted context omitted.

I'm interested. When you say almost, can you elaborate on any remaining use cases when you'd use Mongo?

At my previous company we made heavy use of its lossy compression feature.

Post by colanderman » Thu, May 18, 2017, 6:14 PM UTC

walrus wrote: post #59

colanderman wrote: post #57

Earlier quoted context omitted.

EDIT: Turns out the below is not true, though you can achieve the same effect with the sub-select syntax. The row value can be a single value from some other query. (Rather than having to pick apart each column from the row value.) That said I think the feature has been there for a while, and now simply the "ROW" keyword is optionally allowed.

Thanks for the explanation! update comment set (modified, body) = (select now(), 'edited comment') where id = 123; You're right, it works the same without the `row` keyword in 9.6.

Post by irrational » Thu, May 18, 2017, 6:26 PM UTC

ubertaco wrote: post #14

jdubs wrote: post #12

Earlier quoted context omitted.

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

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'

Post by irrational » Thu, May 18, 2017, 6:30 PM UTC

metalliqaz wrote: post #28

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'

I'm no Postgres master by any means, but I searched it: https://duckduckgo.com/?q=postgres+case+insensitive+query solution immediately came up at SO: SELECT id FROM users WHERE LOWER(email)=LOWER('Foo@example.com')