Live data from Hacker News

PostgreSQL 10 Beta 1 Released

postgresql.org

21–30 of 172 posts

Re: PostgreSQL 10 Beta 1 Released

#21
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'

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');

Re: PostgreSQL 10 Beta 1 Released

#22
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'

Postgres also has the citext column type to make this a snap.

https://www.postgresql.org/docs/9.6/static/citext.html

Re: PostgreSQL 10 Beta 1 Released

#23
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'

The citext type automatically does case-insensitive comparisons: https://www.postgresql.org/docs/current/static/citext.html

Re: PostgreSQL 10 Beta 1 Released

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

Re: PostgreSQL 10 Beta 1 Released

#25
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'

Because you don't always want to match 'Foo' to 'foo'?

Re: PostgreSQL 10 Beta 1 Released

#26
post #10
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.

I feel like this feature replaces almost all of Mongo's use cases!

As soon as Postgres adds the "random data loss" feature they will have a full superset of Mongo.

Re: PostgreSQL 10 Beta 1 Released

#27

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

Does PostgreSQL offer something comparable to MySQL multi-source replication in combination with auto_increment_offset?

Re: PostgreSQL 10 Beta 1 Released

#28
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'

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')

Re: PostgreSQL 10 Beta 1 Released

#29
post #12

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. :/

Honestly, MySQL/MariaDB use has more do with features PostgreSQL didn't have until now. (i.e. Logical replication)

Re: PostgreSQL 10 Beta 1 Released

#30
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…

Has anything actually changed with the ROW syntax for UPDATE? Maybe I'm missing something but it looks like the functionality has always been there, but now you're allowed to type the word "ROW". E.g. compare [1] and [2].

[1] https://www.postgresql.org/docs/9.6/static/sql-update.html [2] https://www.postgresql.org/docs/10.0/static/sql-update.html

Post reply on HN