Page Comparison

...

1. Handle the password. This link describes the approach taken. Basically, we store the password in a file and that way we don’t need to enter the it every time a command is executed.
       https://www.postgresql.org/docs/current/libpq-pgpass.html
   2. We need a maintenance-db. This link describes why it is necessary, but essentially it specifies, for instance for the create database command, the name of the database to connect to when creating the new database. Some documentation that explains the usage of this parameter:
   1. https://www.postgresql.org/docs/current/app-createdb.html
   2. https://www.postgresql.org/docs/current/app-dropdb.html

As part of the Spike ticket. All the tests for DateDim are working fine for Postgres. And in the operations section, the tests that validate the installation of the EWS collection are working fine as well. 

...

1. In our TestHarness class we have a connection string variable, it would be better to have these strings in a separate file instead of hardcoded in the class.
2. We have tests for checking that the columns returned by the view are correct in number and type. It is necessary to create tests specific for Postgres given the fact that the types not necessarily match.
3. As mentioned above, it will be necessary to duplicate the file with the inserts and change it as necessary to make it work for Postgres. 

   In our Operations section we have a set of tests associated to the RLS collection, these tests include checking that a stored procedure is created. The script looks something like this:

   Code Block
   language sql
   SELECT 1 FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'analytics_config' AND ROUTINE_NAME = '{procedureName}'

   We will need to find the equivalent for Postgres.
4. In a similar, the tests associated to when uninstalling the view include some scripts. We will need to find the equivalent for Postgres.
   Nice to have.

...