how to modify search_path when using pg_dump for brownfield (#6497)

content/200-orm/300-prisma-migrate/050-getting-started.mdx

@@ -6,12 +6,8 @@ sidebar_label: 'Getting started'
 tocDepth: 3
 ---
 
-<TopBlock>
-
 This page explains how to get started with migrating your schema in a development environment using Prisma Migrate. See [Developing with Prisma Migrate](/orm/prisma-migrate) for a more in-depth development workflow.
 
-</TopBlock>
-
 ## Get started with Prisma Migrate from scratch
 
 To get started with Prisma Migrate in a development environment:
@@ -161,7 +157,6 @@ The steps involved in **adding Prisma Migrate to your existing project** are:
 Make sure your Prisma schema is in sync with your database schema. This should already be true if you are using a previous version of Prisma Migrate.
 
 1. Introspect the database to make sure that your Prisma schema is up-to-date:
-
    ```terminal
    prisma db pull
    ```
@@ -170,48 +165,37 @@ Make sure your Prisma schema is in sync with your database schema. This should a
 
 Baselining is the process of initializing a migration history for a database that:
 
-- ✔ Existed before you started using Prisma Migrate
-- ✔ Contains data that must be maintained (like production), which means that the database cannot be reset
+- Existed before you started using Prisma Migrate
+- Contains data that must be maintained (like production), which means that the database cannot be reset
 
 Baselining tells Prisma Migrate to assume that one or more migrations have **already been applied**. This prevents generated migrations from failing when they try to create tables and fields that already exist.
 
 To create a baseline migration:
 
 1. If you have a `prisma/migrations` folder, delete, move, rename, or archive this folder.
-
 1. Run the following command to create a `migrations` directory inside with your preferred name. This example will use `0_init` for the migration name:
-
-   ```terminal
-   mkdir -p prisma/migrations/0_init
-   ```
-
-   <Admonition>
-
-   The `0_` is important because Prisma Migrate applies migrations in a [lexicographic order](https://en.wikipedia.org/wiki/Lexicographic_order). You can use a different value such as the current timestamp.
-
-   </Admonition>
-
-1. Generate a migration and save it to a file using `prisma migrate diff`
-
-   ```terminal no-lines
-   npx prisma migrate diff \
-   --from-empty \
-   --to-schema-datamodel prisma/schema.prisma \
-   --script > prisma/migrations/0_init/migration.sql
-   ```
-
-1. Review the generated migration
+    ```terminal
+    mkdir -p prisma/migrations/0_init
+    ```
+    :::note
+    The `0_` is important because Prisma Migrate applies migrations in a [lexicographic order](https://en.wikipedia.org/wiki/Lexicographic_order). You can use a different value such as the current timestamp.
+    ::::
+1. Generate a migration and save it to a file using `prisma migrate diff`:
+    ```terminal no-lines
+    npx prisma migrate diff \
+    --from-empty \
+    --to-schema-datamodel prisma/schema.prisma \
+    --script > prisma/migrations/0_init/migration.sql
+    ```
+1. Review the generated migration.
 
 ### Work around features not supported by Prisma Schema Language
 
 To include [unsupported database features](/orm/prisma-migrate/workflows/unsupported-database-features) that already exist in the database, you must replace or modify the initial migration SQL:
 
 1. Open the `migration.sql` file generated in the [Create a baseline migration](#create-a-baseline-migration) section.
-
 1. Modify the generated SQL. For example:
-
-  - If the changes are minor, you can append additional custom SQL to the generated migration - the following example creates a partial index:
-
+  - If the changes are minor, you can append additional custom SQL to the generated migration. The following example creates a partial index:
     ```sql
     /* Generated migration SQL */
 
@@ -220,15 +204,11 @@ To include [unsupported database features](/orm/prisma-migrate/workflows/unsuppo
       WHERE success;
     --add-end
     ```
-
-  - If the changes are significant, it can be easier to replace the entire migration file with the result of a database dump ([`mysqldump`](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html), [`pg_dump`](https://www.postgresql.org/docs/12/app-pgdump.html))
-
-<Admonition type="info">
-  Note that the order of the tables matters when creating all of them at once,
-  since foreign keys are created at the same step. Therefore, either re-order
-  them or move constraint creation to the last step after all tables are
-  created, so you won't face `can't create constraint` errors
-</Admonition>
+  - If the changes are significant, it can be easier to replace the entire migration file with the result of a database dump ([`mysqldump`](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html), [`pg_dump`](https://www.postgresql.org/docs/12/app-pgdump.html)). When using `pg_dump` for this, you'll need to updade the `search_path` as follows with this command: `SELECT pg_catalog.set_config('search_path', '', false);`; otherwise you'll run into the following error: `The underlying table for model '_prisma_migrations' does not exist.`
+`
+    :::info
+    Note that the order of the tables matters when creating all of them at once, since foreign keys are created at the same step. Therefore, either re-order them or move constraint creation to the last step after all tables are created, so you won't face `can't create constraint` errors
+    :::
 
 ### Apply the initial migrations