Add PostgreSQL configuration example

[dacostafilipe]

Example of the configuration we use internally for using PostgreSQL with ddev

[rfay]

So awesome. I made a few comments, worth minor updates. Most important is you'll probably want a docker volume.

For Drupal 8, the technique would be:

• Edit settings.php and add to the bottom (below settings.ddev.php inclusion):

$databases['default']['default'] = array(
  'database' => "db",
  'username' => "db",
  'password' => "db",
  'host' => 'postgres',
  'driver' => 'pgsql',
);

[rfay]

(Why?)

[dacostafilipe]

In most of our project, we need some kind of spatial search (locations around you, locations in polygon, distance between locations, ... ) and it's really easy and fast with PostGIS. Until activated, there's zero performance penalty.

[rfay]

I was saying to say "why" in the README or docker-compose file. So people can understand why you made the choice (and maybe understand whether they should also be using this, or maybe the library version)

[rfay]

How about a docker volume for the Postgres data so it's not volatile?

[rfay]

A note: People will often want to use the 'php' project type, so that ddev doesn't naively try to mess with their database configuration (AdditionalConfiguration.php or settings.ddev.php, etc)

[rfay]

Wouldn't a docker volume suit most people better?

[dacostafilipe]

I don't remember why we did it that way, will look into this.

[dacostafilipe]

Well, seems like it was just an example of calculated laziness. We needed the import/export commands and they "just worked" for us when restarting projects.

[rfay]

$ ddev pgsql_export
WARNING: The DDEV_URL variable is not set. Defaulting to a blank string.
bash: /mnt/ddev_config/import-db/postgresql.db.sql: No such file or directory
Failed to run pgsql_export : exit status 1

I don't think the import-db directory is ever there in ddev any more, it's from long-ago versions of ddev?

Wouldn't it be better to export to stdout though? Let people do with that what they will?

DDEV_URL is obsolete, I'll comment there.

[dacostafilipe]

I don't think the import-db directory is ever there in ddev any more, it's from long-ago versions of ddev?

1.9 I think.

Wouldn't it be better to export to stdout though? Let people do with that what they will?

That's how the script worked at the beginning. But I had issues with the import part where I did not find an easy way to pass stdin into su -c. I will rewrite the import to create a temp file with the stdin instead.

[dacostafilipe]

The changes to the commands do not seems to work correctly. Executing them manually works, but running them in the hooks does not. Could be stdin/stdout issue as it worked before the change.

[dacostafilipe]

I reverted the commands for now.

[rfay]

@dacostafilipe I pushed some minor changes to the readme and the commands in 15d9701 - if this is OK with you and you're ready for this to be pulled I'll pull it.

[dacostafilipe]

I'm okay with the changes. Added those to my projects.

[rfay]

ddev/ddev#1819 will add the ability to omit the db container, and it will be good to add that here, it should make things less confusing for people.

[steffenr]

We are using pgsql for one of our clients in a ddev setup. Usually we "fire" some post-import-db Commands after DB Import. But those commands are not fired after importing the pgsql.

Is this still possible?

[dacostafilipe]

@steffenr

Yes, it works on our postgresql project.

Our hooks look like this:

hooks:
  pre-start:
    - exec-host: bash .ddev/run-os-export.sh
  pre-stop:
    - exec-host: ddev pgsql_export
  post-start:
    - exec-host: ddev pgsql_import
    - exec: ./console.php queue:worker --queueType=realtime

[steffenr]

@dacostafilipe
You are using the global hooks - we had the post-db-import hook for firing our commands. Those commands are triggered every ddev start/ stop
In our case we only want to reset password/ activate stage_file_proxy after importing the db.

[rfay]

Since importing doesn't use ddev import-db you can't use the post-import-db hooks. But you can use a post-start hook that runs a script that's smart enough to check to see if stage_file_proxy is already activated, for example, and if not, activate it. Or use a flag in the database or on disk.