petereisentraut

The problem with this and similar requests is that it would change the identifier scoping in incompatible ways and therefore potentially break a lot of existing SQL code.

The working group also discussed ORDER BY ALL, but for some reason most participants really did not like it.

This was also discussed at the last SQL WG meeting but was postponed for further refinement. But it’s likely to be added soon.

Git 2.38.0 is the version where git archive uses an internal gzip implementation instead of calling the actual external gzip. This internal implementation has two improvements for this purpose: First, it doesn't store the timestamp. You could also get that with gzip -n. (But the old git archive didn't do that, so you have to run the gzip as a separate step after git archive.) Second, it stores the platform identification bits as "UNIX" on all platforms, so the output is identical on all platforms. There is no gzip command-line option for that, unfortunately.

The configure generated from configure.ac has always been checked into Git for PostgreSQL. So with either the old or the new make dist approach, the configure in the tarball matches the one checked into the source code repository. So this is outside of what this article is discussing.

> - Support for deferring NOT NULL and CHECK constraints to the end of a transaction (just ran into this problem yesterday)

I'm curious what the use case of this is?

Deferrable constraints are usually considered for foreign keys, since there you might have to juggle updates to multiple tables and might violate the constraint in the intermediate states. But that doesn't appear to apply in that way to CHECK constraints.

> Care to explain why you think NULLS DISTINCT is the "right" default behavior? What problems does it solve to warrant additional complexity by default?

It's the most consistent with the equality behavior of null values elsewhere.

I am the author of this feature. The background here is that the SQL standard was ambiguous about which of the two ways an implementation should behave. So in the upcoming SQL:202x, this was addressed by making the behavior implementation-defined and adding this NULLS [NOT] DISTINCT option to pick the other behavior.

Personally, I think that the existing PostgreSQL behavior (NULLS DISTINCT) is the "right" one, and the other option was mainly intended for compatibility with other SQL implementations. But I'm glad that people are also finding other uses for it.

It's a bit more complicated than that. You will also notice another release note item in PG13 that says "Allow inserts, not only updates and deletes, to trigger vacuuming activity in autovacuum", which is because vacuum is not only about cleaning up deleted or rolled-back rows, but also transaction ID wraparound. Making that go away is also a dream of many, but it's a different (or additional) project than a new storage system.

This is also much faster than the equivalent using a PL/pgSQL trigger.

A snapshot is actually just a struct with a few transaction IDs (xids) and some other bookkeeping that describes which slice of the physically stored data is supposed to be visible to a transaction. The article shows the details of that. So the size of a snapshot is unrelated to the size of the database.

Caps Lock is already mapped to Control.

The problem with this is that time zone definitions change, both in the future because of political and administrative changes, as well as in the past, when mistakes are corrected. So a datum like "1st of May 2022 6pm in London" is not a fixed time. And therefore, you can't do any useful computations with this, like what is the time interval between then and the current time, or is this timestamp before, the same, or after, "1st of May 2022 6pm in Madrid". You can't even compare timestamps in the same time zone, because on some days you don't know whether 2am != 3am. Without the ability to do computations or even basic comparisons, such a type wouldn't be very useful in a database.