Hacker News: postgressomethi

New comment by postgressomethi in "An unordered list of things I miss in Go"

postgressomethi — Sat, 17 Aug 2024 23:27:10 +0000

I always thought there should be a two-arg overload of new, so you could write new(bool, true) or new(int, 20). Would solve the problem without any trickery.

New comment by postgressomethi in "Nintendo blitzes GitHub with over 8k emulator-related DMCA takedowns"

postgressomethi — Mon, 06 May 2024 14:45:37 +0000

A Nintendo Switch is a non-hardware decryption system?

New comment by postgressomethi in "Nintendo blitzes GitHub with over 8k emulator-related DMCA takedowns"

postgressomethi — Sat, 04 May 2024 08:07:25 +0000

Could "effectively controls access" be attacked here? The purpose of the hardware is not to control access.

New comment by postgressomethi in "Common DB schema change mistakes in Postgres"

postgressomethi — Tue, 30 Apr 2024 02:36:34 +0000

> You might think adding a UNIQUE index would cause the "losing" xact to get constraint errors, but instead both xacts succeed and no longer have a race condition.

This is not true. What happens is that the (sub)transaction that loses the race to the index is aborted:

  =# INSERT INTO foo (bar) (SELECT max(bar) + 1 FROM foo);
  ERROR:  duplicate key value violates unique constraint "foo_bar_idx"
  DETAIL:  Key (bar)=(2) already exists.

New comment by postgressomethi in "There has never been a better time to game on Linux"

postgressomethi — Fri, 12 Jan 2024 19:44:42 +0000

> Imagine booting your computer and having to give an email to login offline.

As much as I hate what modern Windows has become, this is not actually true. If you know the correct sequence of clicks you can avoid this. Not defending this bullshit, though.

New comment by postgressomethi in "How I destroyed the company's DB (a stupid SQL mistake)"

postgressomethi — Mon, 01 Jan 2024 20:09:57 +0000

Ah, now I see I responded to the wrong message.

New comment by postgressomethi in "How I destroyed the company's DB (a stupid SQL mistake)"

postgressomethi — Mon, 01 Jan 2024 19:57:30 +0000

I'm sorry, I wasn't being clear. Any column meaning "this row is to be ignored for most applications" is an annoying pattern.

New comment by postgressomethi in "How I destroyed the company's DB (a stupid SQL mistake)"

postgressomethi — Mon, 01 Jan 2024 19:35:28 +0000

While that's kind of convenient in a lot of ways, it also makes querying the database really annoying, since you have to remember to add the filtering to every single query or you're screwed. Personally, I wish there was a database-implementation-acknowledged "deleted" flag, which could even expose a "history table"-like interface.

New comment by postgressomethi in "Ways to capture changes in Postgres"

postgressomethi — Fri, 22 Sep 2023 13:37:30 +0000

Sequences kind of have the same issue, because you don't know if a gap is because of a rollback or an uncommitted transaction. Though with some logic you can do a pretty good job at this with sequences. And then you're not in the realm of "simple" anymore, at all.

New comment by postgressomethi in "Ways to capture changes in Postgres"

postgressomethi — Fri, 22 Sep 2023 13:00:02 +0000

Polling an updated_at column is not robust in its most simple form, as transactions are not guaranteed to commit in that order.

New comment by postgressomethi in "Zero-downtime schema migrations in Postgres using views"

postgressomethi — Thu, 17 Jun 2021 22:39:40 +0000

No.

New comment by postgressomethi in "Zero-downtime schema migrations in Postgres using views"

postgressomethi — Thu, 17 Jun 2021 09:50:03 +0000

That's still, in my opinion, overkill and unnecessary.

New comment by postgressomethi in "Zero-downtime schema migrations in Postgres using views"

postgressomethi — Wed, 16 Jun 2021 23:08:07 +0000

> Adding a column, changing column's nullability and adding/changing constraints is already zero-downtime in PG.

Making a previously nullable column NOT NULL is not zero downtime. Neither are adding constraints -- except in some cases with NOT VALID, which isn't quite the same thing.

> Dropping a column and changing the data type are not zero-downtime.

Dropping a column is zero downtime.

New comment by postgressomethi in "Zero-downtime schema migrations in Postgres using views"

postgressomethi — Wed, 16 Jun 2021 23:01:45 +0000

I don't like really solutions which force everything into a single schema just to do migrations. They shouldn't be that difficult.

In this particular case, rather than making everything a view all the time, you could just use views during a migration window to get the same effect. Replace the table with a view which has all the columns plus the new name as an alias for the old one, migrate all the clients, replace the view with the table with the column renamed. No special permanent crap necessary.

New comment by postgressomethi in "Do you really need Redis? How to get away with just PostgreSQL"

postgressomethi — Sun, 13 Jun 2021 08:09:34 +0000

> This approach doesn’t work for LISTEN because typically a client will listen for its entire lifecycle so you can’t share connections in a pool.

But you only need one connection for LISTEN per database, total. So I'm confused why this is made out to be a big issue.

New comment by postgressomethi in "The code on the laptop in the stock photo at developer.bbc.com is user-editable"

postgressomethi — Sun, 13 Jun 2021 00:09:41 +0000

Can this quote die already? Rob has repeatedly demonstrated he doesn't know what's best for everyone.

New comment by postgressomethi in "Do you really need Redis? How to get away with just PostgreSQL"

postgressomethi — Sat, 12 Jun 2021 18:51:47 +0000

> LISTEN ties up one connection completely

I've seen this twice in this thread, but I don't know what that means. Can you explain a bit?

New comment by postgressomethi in "EU Parliament Wants Pirated Sports Streams Taken Down Within 30 Minutes"

postgressomethi — Sun, 11 Apr 2021 18:50:06 +0000

Huh? The VPN isn't for privacy.

New comment by postgressomethi in "Securing a Postgres Database"

postgressomethi — Fri, 02 Apr 2021 21:23:12 +0000

> Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost.

I don't know what the defaults are, but pg_ident.conf has absolutely nothing to do with this. The main configuration file (I think postgresql.conf usually) has listen_addresses, which controls the addresses on which postgres listens, as you might guess.

pg_hba.conf (not pg_ident.conf) controls the authentication methods the server asks from the client, depending on how they're connecting.