The run command mentioned in the README should be extracted into a script so that someone can simply clone the repository and run the script, instead of copying a command.

It can also be shortened, depending on how portable one does want it. For example this is the shortest incarnation I can come up with:

ls -v *.sql | xargs psql -f

However, the -v flag of ls is not portable and is most likely only available in the GNU version...but so is the -V flag of sort, as far as I am aware. So the most portable script is most likely this one:

ls *.sql | sort -n | xargs psql -f

SELECT ARRAY(SELECT col1 FROM ( VALUES (1), (2), (3) ) vals (v)); -- {1,2,3}

basically equivalent to SELECT (SELECT array_agg(col1) ...)

I'm not sure whether one performs better than the other but the ARRAY() form seems more natural when working in a scalar subquery context.

I just have this impression, from vague recollection of list emails and some fading first-hand experience, that the implementation details of domains when used in casting/functions makes using them potentially problematic.

I'm running 1920x1080 and have to scroll to see the end of commands and comment in GitHub. Especially for tutorial intended work that is undesirable.

To avoid fork for each language maybe we could add a script (like bash for Linux) which remplace all english comment to a translated one ?

I'd probably introduce SQL language "functions" first and describe them (and SQL generally) as being an imperative language.

Then when introducing pl/pgsql I'd highlight that it is a procedural language and should be chosen when SQL cannot solve the problem at hand - in particular since executing queries with SQL functions can be optimized moreso that queries with pl/pgsql functions.

I seem to recall "stored procedures" having a "standalone transaction context" associated with them while functions always execute within the same transaction as the caller. I'd change the name for 20_stored_procedures.sql for this reason; though I guess it depends on what the target audience is more likely to expect.