Allow "initdb.d" scripts to be (optionally) sourced instead of executed

Kind-of the opposite of #452 (which fixes #450), but I'd be fine with the current behavior by default provided there can be some means (file name or extension) of sourcing instead of executing.

Rationale:

I have an initialization script that needs file_env(), $POSTGRES_DB, and ${psql[@]}.

When the script is sourced it works, but as none of those are exported, it doesn't work if it's executed. We've had to take care to chmod -x the file to work around this after #452, but that seems kind-of hacky and hard to maintain.

Possible options:

Informal naming convention, e.g. source_*.sh, *.source.sh, .*, or similar
- Might be hard to document, know about
- Could be triggered accidentally by unaware users
Separate directory or subdirectory
Export (optionally?) useful functions/variables
- Hard to maintain
- Maybe undesirable by default for some users?
Have the default case try to source $f instead of ignoring it
- Maybe users are exploiting current behavior and putting weird files here for some reason

Thoughts?

If you remove the executable bit from your .sh file, it will be sourced instead of run:

postgres/docker-entrypoint.sh

Line 148 in 91939da

if [ -x "$f" ]; then

(As in, this is working as designed, and I'm not sure I understand how/why it's difficult to maintain a chmod -x, so you might need to elaborate a bit. 👍)

Related #452

@tianon Well, nominally it's not that hard. But since I'm on a windows host it means I had to COPY the file in my Dockerfile instead of mount it in my docker-compose.yml (as you mentioned here). That's really undesirable/annoying for me personally.

Ah, one simple workaround could be to mount it somewhere else, and adjust your command: to copy/chown it before starting up postgres, something like:

  db:
    image: postgres:10
    command: sh -c 'cp /tmp/xyz.sh /docker-entrypoint-initdb.d/ && chmod -x /docker-entrypoint-initdb.d/xyz.sh && exec docker-entrypoint.sh postgres'
    volumes:
      - ./xyz.sh:/tmp/xyz.sh:ro

That's a better workaround indeed.

Still, it seems like many (most?) users would want access to the environment of docker_entrypoint.sh, no? It's good there's a choice, but something a little more declarative than the executable bit (for Windows hosts especially) sounds nicer to me.

If nobody else agrees, though, I can live with the workaround :)

@tianon Unless I'm mistaken, for that workaround the entrypoint needs to be changed (from docker-entrypoint.sh) as well, right?

I mean, you can, but it will automatically ignore this command and pass it straight through (since "$1" isn't "postgres"), so it's harmless either way (and more readable this way than munging "entrypoint:" too, IMO).

Ah, that's what it does. I was confused I think, I didn't re-run docker_entrypoint!