I agree about the main drawback; I'd rather not publish a breaking change. The sorting of a find should be about the same as globing; we can even make sure that everything within a directory comes before sub-directories. Maybe we hide it behind an environment flag to turn it on? If we were to add it would we limit the depth when finding scripts/sql?

Maybe we just recommend users mount a script and have it run other scripts in their folders.

@yosifkit I think your second suggestion sounds better than adding another environment variable

Also, I thought find uses readdir order

My solution is mounting ./initdb.d folder to /initdb.d and ./initdb.sh script to /docker-entrypoint-initdb.d/initdb.sh:

for f in /initdb.d/*.sql; do
  echo "$0: running $f"
  "${psql[@]}" -f "$f"
done

A simple solution is to create a file (init.sh inside /docker-entrypoint-initdb.d/initdb.sh) with the following content:

#!/usr/bin/env bash
find /docker-entrypoint-initdb.d -mindepth 2 -type f -print0 | while read -d $'\0' f; do
  case "$f" in
    *.sh)
      if [ -x "$f" ]; then
        echo "$0: running $f"
        "$f"
      else
        echo "$0: sourcing $f"
        . "$f"
      fi
      ;;
    *.sql)    echo "$0: running $f"; "${psql[@]}" -f "$f"; echo ;;
    *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${psql[@]}"; echo ;;
    *)        echo "$0: ignoring $f" ;;
  esac
  echo
done

This will recurse all sub-directories inside /docker-entrypoint-initdb.d/ and run the files the same way the original Dockerfile do

Closing since this is not something we want to add.

Since initdb scripts can be sourced (#452) and everything in the script is functionalized (#496), a custom script in initdb can easily use the docker_process_init_files function to recurse as deeply as desired.

Related issues #179, #605, docker-library/mysql#192, docker-library/mysql#193