For the coverage-aware holiday-calendar API in TSAPI core (db_base
holiday_calendar__get / __set_coverage / __set_metadata / __upsert).
- meta.holiday_calendars (name, description, covered_from, covered_to,
source, updated_at): a calendar exists when it has a row here, not
when it has holidays (retires the 9999-12-31 sentinel row).
covered_from/to: the range over which the closure list is complete;
both set or both NULL, from <= to (holiday_calendars_coverage_check).
- Calendar names are citext in every table (registry, holidays.calendar_name,
exchanges.default_holiday_calendar, instruments.holiday_calendar):
stored as given, unique and matched case-insensitively -- also in the
foreign keys -- as the native TSAPI backend does with COLLATE NOCASE.
New extension citext (00_extensions.sql). Name check: non-empty,
trimmed, <= 50 characters.
- FKs: holidays -> registry ON DELETE CASCADE; exchanges/instruments ->
registry ON DELETE RESTRICT (a calendar in use cannot be dropped);
ON UPDATE CASCADE everywhere.
- meta.series.num_records dropped. Only some write paths maintained it
(never C++), it sometimes held an estimate, and it was NULL for a series
never written to. Clients ask the table: count(*), or
SELECT EXISTS (SELECT 1 FROM <table>) for "is it empty?".
- find_schema_problems() covers the new table, columns, constraints and
extension, and runs with search_path = pg_catalog so format_type()
reports 'public.citext' whatever the caller's search_path.
Verified on a fresh database (PG 17): run_setup.py installs it and
find_schema_problems() returns zero rows, also for a caller without
public on the search_path; constraint behaviour checked by hand
(case-insensitive duplicate refused, FK matches any spelling, RESTRICT
and CASCADE, coverage and name checks).
Re-provision databases (no migration).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The definition string is the only stored schedule. The "json" column held a
parsed copy that the Python client wrote, the C++ client never wrote, and
neither client read -- and a raw UPDATE of one field silently left two
different schedules. Clients derive the parsed form from the definition.
09_schema_check.sql no longer expects the column; VERSION and
10_schema_version.sql at 1.4.0. Re-provision databases (no migrations).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An occasional consistency check (not for connect time) comparing
meta.series with the registered series schemas: non-series tables, views,
sequences and functions inside a series schema; registered series whose
table is missing; series tables without a timestamp column or its BRIN
index. Report only; user schemas are never examined. find_schema_problems()
fingerprints its body like every other procedure.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- meta.series_schemas (name, description, created_at, created_by), seeded
with 'series'. FK series_db_schema_fkey from meta.series.db_schema: a
series may only live in a registered schema, for every client.
Unregistered schemas belong to the user and are never touched.
- CHECK series_schemas_name_check and series_table_name_check enforce the
shared lower-case identifier rule in the database.
- meta.find_schema_problems() covers the registry and reports a registered
schema that no longer exists; user schemas are not examined.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
meta.find_schema_problems() (09), the version row in the DDL (10), every
install running 00-10, and the removal of sql/migrate/ changed what a
complete database is. Databases from 1.0.0 are re-provisioned.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
09_schema_check.sql adds meta.find_schema_problems(), a read-only check
any client (Python, C++, psql) can call:
SELECT * FROM meta.find_schema_problems(); -- zero rows = usable
One row per problem (object, problem): missing schemas, extension,
sequences, tables, columns, wrong column type or NOT NULL, missing
constraints, indexes, views, stored-function bodies that differ from the
DDL (whitespace-insensitive md5 fingerprint), a missing/disabled/
misdirected event trigger, short reference data, no version row. It
mirrors 00-08 and must change in the same commit as they do; the
release test (a fresh install returns zero rows) enforces that.
10_schema_version.sql records VERSION in meta.schema_version. Before,
only the Python client wrote that row, so databases provisioned by
run_setup.py recorded no version at all.
run_setup.py now runs 00-10. It skipped 08_script_log.sql, so its
databases lacked a table the Python client uses; every fresh install is
now identical regardless of provisioner.
sql/migrate/ is removed: databases are re-provisioned, not migrated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
