SchemaTongs for PostgreSQL

From the directory containing your SchemaTongs.settings.json:

SchemaTongs

With a custom config file:

SchemaTongs --ConfigFile:/etc/schemasmith/extract-staging.json

With a full PostgreSQL connection string override:

SchemaTongs --ConnectionString:"Host=myserver;Port=5432;Database=northwind;Username=tongs;Password=secret;"

SchemaTongs connects to the source database, reads every enabled object type, and writes the results to the configured product path. On first run it creates the full package structure; on subsequent runs it updates existing files in place and preserves any custom metadata you have attached under Extensions.

Schema-only mode

If you just need to regenerate the .json-schemas/*.schema validation files for an existing product — without connecting to a database — use the --WriteSchemasOnly switch:

SchemaTongs --WriteSchemasOnly --Product:Path:./my-product

This reads the Platform from Product.json, regenerates the schema files on the fly from the current engine's C# domain types, and exits. No database connection, no extraction. Useful when you've updated SchemaSmith and want CI validation to match the new engine without re-extracting.

Control exactly what gets cast from the database. Each object type can be individually enabled or disabled.

The ObjectList setting restricts extraction to a specific set of objects. Provide a comma- or semicolon-separated list of object names:

"ShouldCast": {
  "ObjectList": "public.customers,public.v_active_customers,usp_get_orders"
}

Names can be specified with or without a schema prefix. Matching is case-insensitive. When ObjectList is empty (the default), all objects matching the enabled ShouldCast flags are extracted.

When ObjectList is active, orphan detection is automatically disabled — SchemaTongs can't tell which files are genuinely orphaned when only a subset of objects is being extracted.

Custom metadata you've attached to your tables under Extensions is preserved across re-extractions. When SchemaTongs writes a table file, it checks whether a previous file existed for the same table and copies the previous Extensions content forward onto the freshly extracted table.

The preservation pass uses the component's Name (with quote/bracket characters stripped, case-insensitive). For columns and the table itself, matching also falls back to OldName, so renamed components keep their custom metadata as long as you set OldName correctly before the rename is deployed.

This is what makes Custom Properties trustworthy across the SchemaTongs / SchemaQuench round-trip: you attach metadata once, and it survives every re-extraction as long as the underlying object stays.

Organize your scripts however makes sense for your team — SchemaTongs respects that structure across re-extractions. Any extracted script folder supports user-created subfolders for organizing scripts. For example, you might organize stored procedures by domain:

Procedures/
  orders/
    public.get_order.sql
    public.create_order.sql
  customers/
    public.get_customer.sql

SchemaTongs preserves these subfolders across re-extraction. Before extraction begins, it builds a file index that maps every .sql, .sqlerror, and .json file to its full path, including any subfolder. When writing an extracted object, SchemaTongs checks the index:

• If the file already exists in a subfolder, it's written back to that same subfolder.
• If the file exists in multiple subfolders, a warning is logged and the file is written to the folder root.
• If the file is new (not in the index), it's written to the folder root.

New objects always appear in the root of their folder. Move them into subfolders as desired — SchemaTongs will remember the location on the next run. This means you can shape your extracted package to fit your code review and team conventions, not the other way around.

On every run, SchemaTongs deploys (or updates) lightweight helper procedures in the source database under the SchemaSmith schema. These procedures generate the JSON representation of tables and views and are used internally by the extraction adapter. They're read-only, schema-prefixed, and excluded from extraction output.

When ShouldCast:ScriptDynamicDependencyRemovalForFunctions is true, SchemaTongs generates a dynamic SQL preamble before each function script. This preamble detects and temporarily removes database objects that depend on the function (computed columns, check constraints, foreign keys involving computed columns, indexes on computed columns or filter expressions referencing the function). At deployment time, SchemaQuench executes the preamble first, dropping all dependents, then creates or alters the function. The dependents are recreated by subsequent steps in the quench (table definitions restore computed columns, constraints, and indexes).

Surgical use only

This is a surgical fix, not a default. Enable it on functions where:

1. The function is referenced by computed columns or filtered indexes, AND
2. Changes regularly enough that manual dependency management is impractical, AND
3. The dependency drop-and-rebuild is acceptably fast.

The risk that makes this opt-in: if a computed column is persisted or indexed on a 500-million-row table, dropping that dependency means rebuilding the persisted column or index after the function is updated — which could take a very long time and impact production availability. For functions that rarely change, the right approach is to leave this flag off and write a migration script that handles the dependencies carefully when the function truly needs to change.