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.

Sure they can. See example here: https://www.postgresql.org/docs/current/plpgsql-transactions...

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.

Right. It will probably be enabled by default in PostgreSQL 12.

You also cannot run VACUUM inside a DO block. It's the same thing underneath.

Now is the time to test this. From my early experiments, you can expect to get speedups for queries that last longer than a few seconds. A lot depends on whether I/O, caching, etc. dominates. The only disadvantage is that it takes time to do the JIT compilation, so if the query is already fast, JIT compilation will probably make it slower. Hence, there are ways to adjust when it should be used.

Feature author here. Running not-allowed-in-transaction-block DDL, such as VACUUM, still won't work in stored procedures. Room for future improvement.

The release notes say Amit Khandekar. (I don't know him.)

Try OmniDB perhaps?

(disclaimer: my employer (but open source))

Another problem is that the bool provided by stdbool.h is 4 bytes on some platforms, which breaks PostgreSQL all over the place.

It has to do with how the tuple header that stores the metadata is designed. See comments here: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...

Any XML document that you can address via XPath in a sensible way. If your XML document is a mess, you'll only be able to get out a mess. :)

To get XML from a table, functions already existed in previous releases (XMLELEMENT etc.).

Not a priority for 2Q at the moment. Still general interest in the community, but hard to predict right now.

Several reasons:

- Checkbox item for people not wanting MD5 anymore.

- Storing passwords on the server in a securely hashed way, so the admin won’t know your password.

- PostgreSQL developers getting out of the roll-your-own-crypto game.

The new logical replication feature is based on the experiences from BDR and pglogical, but it isn't multimaster yet.

fixed, thanks

Or if you use Homebrew you might like: brew install --devel petere/postgresql/postgresql@10

I'm not familiar with MySQL, but this might be along those lines: https://www.2ndquadrant.com/en/resources/bdr/

ICU collations are prepopulated; see <https://www.postgresql.org/docs/devel/static/collation.html#....

Also, ICU collations are case sensitive, just like libc locales.