This is a short summary. ↗ Open original to view full content
Waiting for PostgreSQL 18 – Enable BUFFERS with EXPLAIN ANALYZE by default
from blog select * from depesz;, | ↗ original
More from select * from depesz;
Waiting for PostgreSQL 18 – Support LIKE with nondeterministic collations
10 Jan 2025 |
original ↗
On 27th of November 2024, Peter Eisentraut committed patch: Support LIKE with nondeterministic collations This allows for example using LIKE with case-insensitive collations. There was previously no internal implementation of this, so it was met with a not-supported error. This adds the internal implementation and removes the error. The...
Waiting for PostgreSQL 18 – psql: Add more information about service name
6 Jan 2025 |
original ↗
On 18th of December 2024, Michael Paquier committed patch: psql: Add more information about service name This commit adds support for the following items in psql, able to show a service name, when available: - Variable SERVICE. - Substitution %s in PROMPT{1,2,3}. This relies on 4b99fed7541e, that has made the service name available … Continue...
Waiting for PostgreSQL 18 – Add UUID version 7 generation function.
31 Dec 2024 |
original ↗
On 11st of December 2024, Masahiko Sawada committed patch: Add UUID version 7 generation function. This commit introduces the uuidv7() SQL function, which generates UUID version 7 as specified in RFC 9652. UUIDv7 combines a Unix timestamp in milliseconds and random bits, offering both uniqueness and sortability. In our implementation, the...
How to ALTER tables without breaking application?
12 Dec 2024 |
original ↗
I once wrote about this problem, but given that we now have DO blocks and procedures I can make nicer, easy to use example. Over the years there have been many improvements to how long ALTER TABLE can take. You can now (in some cases) change datatype without rewrite or add default value. Regardless how … Continue reading "How to ALTER tables...
SQL best practices – don’t compare count(*) with 0
1 Dec 2024 |
original ↗
Every now and then I see something like this: SELECT u.* FROM users u WHERE 0 = (SELECT COUNT(*) FROM addresses a WHERE a.user_id = u.id); and it kinda pains me. So figured, I'll write about what is the problem with it, and how to avoid such constructs. Lets consider what went through someones mind … Continue reading "SQL best practices – don’t...