The VICTOR_ACCOUNT arm of bankAccountView — CFX's core accounts at
Dart, with balances implied from the bank_transaction feed.
The simplest of the five arms, and the one that establishes the shape the
other four follow: a NOT MATERIALIZED CTE that resolves the source row and
its owner, then one outer SELECT projecting bankAccountViewColumns() in
declared order with the balance lateral joined on keyable.
bank_id is the 'dart' literal rather than a column: victor_account has
no bank FK because Victor is the Dart integration, and 'dart' is exactly
what victorTransactionSyncActivities writes to bank_transaction.bank_id
for these accounts. Every row here is keyable — both account columns are
NOT NULL on the table.
parent_key is deliberately NULL even for per-customer FBO rows. The table's
own comment says a master pooled FBO carries a null customer_id, but
whether per-customer FBOs are sub-ledgers of that pool or independent
accounts at Dart is not something the schema states, and a wrong edge
produces a confidently wrong rollup — see § 4.5 and open question 3.
dbmate owns the DDL: the body below is mirrored by
20260814200000_bank_account_view.sql. securityInvoker is required, not
decoration — every underlying table has RLS enabled, and without it the view
would run with the owner's row visibility and silently bypass the querying
role's policies.
The
VICTOR_ACCOUNTarm of bankAccountView — CFX's core accounts at Dart, with balances implied from thebank_transactionfeed.The simplest of the five arms, and the one that establishes the shape the other four follow: a
NOT MATERIALIZEDCTE that resolves the source row and its owner, then one outer SELECT projectingbankAccountViewColumns()in declared order with the balance lateral joined onkeyable.bank_idis the'dart'literal rather than a column:victor_accounthas no bank FK because Victor is the Dart integration, and'dart'is exactly whatvictorTransactionSyncActivitieswrites tobank_transaction.bank_idfor these accounts. Every row here is keyable — both account columns areNOT NULLon the table.parent_keyis deliberately NULL even for per-customer FBO rows. The table's own comment says a master pooled FBO carries a nullcustomer_id, but whether per-customer FBOs are sub-ledgers of that pool or independent accounts at Dart is not something the schema states, and a wrong edge produces a confidently wrong rollup — see § 4.5 and open question 3.dbmate owns the DDL: the body below is mirrored by
20260814200000_bank_account_view.sql.securityInvokeris required, not decoration — every underlying table has RLS enabled, and without it the view would run with the owner's row visibility and silently bypass the querying role's policies.