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

[dakotahawkins]

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:

1. 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
2. Separate directory or subdirectory
3. Export (optionally?) useful functions/variables
   • Hard to maintain
   • Maybe undesirable by default for some users?
4. 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?

[tianon]

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

[tianon]

(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. 👍)

[wglambert]

Related #452

[dakotahawkins]

@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.

[tianon]

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

[dakotahawkins]

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 :)

[dakotahawkins]

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

[tianon]

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).

[dakotahawkins]

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