Conventions spell calendars in a vocabulary ORE refuses

A convention row holds a calendar, and two vocabularies spell one: refdata.calendars holds codes such as UnitedStates.Settlement, UnitedStates.SOFR and UnitedKingdom.Settlement, while ORE reads its own calendar names, US, US-SOFR, TARGET, and refuses everything else. The convention populate scripts use the first vocabulary. ORE's parseCalendar refuses all three of those dotted spellings, so a convention exported as it stands names a calendar the engine cannot build.

The index conventions were mined from the engine and now carry ORE's calendar names, which is what ores_refdata_validate_calendar_fn reads and the parser accepts. The currency pair conventions were not: refdata_currency_pair_convention_calendars_populate.sql and its seed twin still hold UnitedStates.Settlement and UnitedKingdom.Settlement.

Two more files still hold the first vocabulary for the same reason: refdata_overnight_index_conventions_populate.sql, whose thirteen remaining rows keep the synthetic feeds' families and their refdata.calendars codes (TARGET, Japan), and refdata_currency_pair_convention_calendars_seed_populate.sql.

Nothing translates between the two vocabularies today. Either the seed moves onto ORE's names, as the index conventions did, or the export translates, and that choice is what this capture is for. The oracle is cheap: the code_catalogue harness tool reads a code and prints the name ORE reports for it, so the inverse table can be derived rather than written by hand.

• projects/ores.sql/populate/refdata/refdata_currency_pair_convention_calendars_populate.sql
• projects/ores.sql/populate/refdata/refdata_currency_pair_convention_calendars_seed_populate.sql
• projects/ores.sql/populate/refdata/refdata_calendar_names_validate_fn_create.sql
• external/ore/tools/datum_catalogue/code_catalogue.cpp
• Seed ORE's built-in index conventions — where the same fault was found and fixed for the index conventions.

• Seed ORE's built-in index conventions