The MANUAL arm of bankAccountView — accounts an operator
registered, with balances implied from the bank_transaction feed.
Anti-joined against victor_account and virtual_account because a manual
registration does NOT outrank the typed tables: those are systems of record
maintained by the provider integrations, and a hand-typed row that shadowed
one would present an operator's transcription as authoritative over Victor's
own record of the account. The inferred arms are the opposite case — they
assert nothing a human confirmed, so a human confirmation wins, which is why
bankInstructionBankAccountView and observedBankAccountView anti-join the
manual TABLE rather than the reverse. See § 4.7.
One consequence of anti-joining the table rather than this view: an account
registered here AND present in victor_account drops from this arm while
still suppressing its BANK_INSTRUCTION row, so it surfaces exactly once,
as VICTOR_ACCOUNT. Anti-joining the view instead would resurrect the
inferred row and produce two.
bank_name prefers the joined partner bank and falls back to the free-text
column, which is the only name a non-partner counterparty bank has.
The balance lateral correlates on the account alone, never on this arm's
memo, and that is deliberate rather than an oversight. A memo here is an
operator's label for a slice of a shared account — not the metcap FFC key
that data -> 'methodData' ->> 'ffcMemo' carries — so narrowing by it would
return zero for every registration that has one. The memo still participates
in key, so two memo'd registrations of one account stay distinct rows that
report the same account-level balance.
dbmate owns the DDL: the body below is mirrored by
20260814200000_bank_account_view.sql.
The
MANUALarm of bankAccountView — accounts an operator registered, with balances implied from thebank_transactionfeed.Anti-joined against
victor_accountandvirtual_accountbecause a manual registration does NOT outrank the typed tables: those are systems of record maintained by the provider integrations, and a hand-typed row that shadowed one would present an operator's transcription as authoritative over Victor's own record of the account. The inferred arms are the opposite case — they assert nothing a human confirmed, so a human confirmation wins, which is whybankInstructionBankAccountViewandobservedBankAccountViewanti-join the manual TABLE rather than the reverse. See § 4.7.One consequence of anti-joining the table rather than this view: an account registered here AND present in
victor_accountdrops from this arm while still suppressing itsBANK_INSTRUCTIONrow, so it surfaces exactly once, asVICTOR_ACCOUNT. Anti-joining the view instead would resurrect the inferred row and produce two.bank_nameprefers the joined partner bank and falls back to the free-text column, which is the only name a non-partner counterparty bank has.The balance lateral correlates on the account alone, never on this arm's
memo, and that is deliberate rather than an oversight. A memo here is an operator's label for a slice of a shared account — not the metcap FFC key thatdata -> 'methodData' ->> 'ffcMemo'carries — so narrowing by it would return zero for every registration that has one. The memo still participates inkey, so two memo'd registrations of one account stay distinct rows that report the same account-level balance.dbmate owns the DDL: the body below is mirrored by
20260814200000_bank_account_view.sql.