Holy smokes I just figured it out!

I was looking into the Ecto code that handles migrations and I found this the area that manages the Primary Key Configuration logic.

deps/ecto_sql/lib/ecto/migration.ex:1660

  @doc false
  def __primary_key__(table) do
    case table.primary_key do
      false ->
        false

      true ->
        case Runner.repo_config(:migration_primary_key, []) do
          false -> false
          opts when is_list(opts) -> pk_opts_to_tuple(opts)
        end

      opts when is_list(opts) ->
        pk_opts_to_tuple(opts)

      _ ->
        raise ArgumentError,
              ":primary_key option must be either a boolean or a keyword list of options"
    end
  end

  defp pk_opts_to_tuple(opts) do
    opts = Keyword.put(opts, :primary_key, true)
    {name, opts} = Keyword.pop(opts, :name, :id)
    {type, opts} = Keyword.pop(opts, :type, :bigserial)
    {name, type, opts}
  end

This is the logic block that pulls the migration_primary_key: [] from the configuration file. Pretty straight forward. Pulls out the :name and :type with a default value if the keys are not defined.

So with that found I was curious to see how the remaining opts are being parsed and coerced before the migration runs.

deps/ecto_sql/lib/ecto/migration.ex:1225

  @doc """
  Generates a fragment to be used as a default value.

  ## Examples

      create table("posts") do
        add :inserted_at, :naive_datetime, default: fragment("now()")
      end
  """
  def fragment(expr) when is_binary(expr) do
    {:fragment, expr}
  end

Finding that was WILD! It means we can likely just pass a tuple with the :fragment key in the config file!?

Tested it out and it worked!!!

priv/repo/migrations/create_users.exs

  def change do
    create table(:users) do
      add :name, :string
      add :type, :integer


      timestamps()
    end
  end

Produces this SQL statement during migration.

CREATE TABLE "users" ("id" uuid DEFAULT gen_random_uuid(), "name" varchar(255) NOT NULL, "type" integer NOT NULL, "inserted_at" timestamp(0) NOT NULL, "updated_at" timestamp(0) NOT NULL, PRIMARY KEY ("id"))

Which results in this Postgres table definition with the default value properly set!

my_app_dev=# \d users
                         Table "public.users"
    Column    |            Type             | Collation | Nullable |  Default
--------------+-----------------------------+-----------+----------+------------
 id           | bytea                       |           | not null | gen_random_uuid()
 name         | character varying(255)      |           |          |
 type         | integer                     |           |          |
 inserted_at  | timestamp without time zone |           | not null |
 updated_at   | timestamp without time zone |           | not null |

Absolutely perfect, I’m very stoked to get this knowledge gap figured out.