feat(checkpoint-postgres): Add support for providing a custom schema during initialization

[nick-w-nick]

This PR adds support for specifying a custom schema in the checkpoint-postgres module during initialization. Instead of relying on the default public schema used by Postgres or modifying the connection string’s search path (which can be unreliable at best), SQL queries now explicitly reference the provided schema, ensuring compatibility across all PostgreSQL versions and configurations, while still allowing the original module to stay backward compatible with previous versions since public was already the default schema.

// you can optionally pass a configuration object as the second parameter
const checkpointer = PostgresSaver.fromConnString("postgresql://...", {
  schema: "schema_name" // defaults to "public"
});

Key Changes

• Custom Schema Support
  • Added an extendable options parameter to specify a schema when creating a PostgresSaver instance via the fromConnString method
  • Consolidated SQL queries and migration scripts into reusable functions that accept a schema name
• Documentation & Testing
  • Improved JSDoc comments for fromConnString with usage example
  • Enhanced integration tests to validate behavior with both the default and a custom schema

[benjamincburns]

Thanks for the contribution! I'll have a closer look tomorrow, but from a quick glance this looks really nice!

[benjamincburns]

Don't worry about the docs deploy - that's expected to fail on external PRs for the moment. 😅

[benjamincburns]

Just one small change requested, please & thanks. Handy change overall, though!

[benjamincburns]

This is kind of a nit, but on first read through I thought that perhaps you were mistakenly causing default options to not be applied by specifying this default value.

It might be more readable/explicit if you have a module-scoped _defaultOptions, kept the options arg here and in the ctor optional, and then conditionally applied that at the start of the method.

[nick-w-nick]

@benjamincburns I've pushed a change to update the default options behavior, including moving it to a module-scoped _defaultOptions variable.

Let me know if this works for you.

Thanks!

[benjamincburns]

Thanks again for the contribution!

[benjamincburns]

Thanks for adding the reference docs, btw!

[benjamincburns]

Thanks for this. In the future you can also just in-line this, as it's a really common pattern for applying defaults. Having it be a well-named function call does express intent more clearly, however.