-- +goose Up

-- PC configurator (like DNS-shop/Regard's component picker) reuses the
-- existing retail-parts catalog rather than a parallel table — a CPU or
-- GPU sold to a client is fundamentally the same kind of row as any other
-- retail part (stock, FIFO cost, sale_price, the existing Продажи
-- checkout), it just also needs compatibility-relevant attributes no
-- other part type has. pc_component_type is NULL for every ordinary
-- repair part (screens, batteries, toner...) — only staff who explicitly
-- tag a part as a PC component populate it.
--
-- pc_spec is JSONB rather than dedicated columns per type — the eight
-- component types need almost entirely different attribute sets (a
-- motherboard's max_ram_gb/ram_slots/form_factor have no CPU equivalent),
-- and a rigid per-type table would mean either eight near-empty tables or
-- one parts table bloated with thirty mostly-NULL columns. Same
-- "structured-enough JSONB on a core table" idiom orders.custom_fields
-- already established (migrations/009) — internal/pcbuilder's
-- compatibility checker is the one place that needs to know the shape per
-- type, not the database.
ALTER TABLE parts ADD COLUMN pc_component_type TEXT
    CHECK (pc_component_type IN ('cpu', 'motherboard', 'ram', 'gpu', 'psu', 'case', 'cooler', 'storage'));
ALTER TABLE parts ADD COLUMN pc_spec JSONB;
CREATE INDEX parts_pc_component_type_idx ON parts (pc_component_type) WHERE pc_component_type IS NOT NULL;

-- +goose Down
DROP INDEX parts_pc_component_type_idx;
ALTER TABLE parts DROP COLUMN pc_component_type;
ALTER TABLE parts DROP COLUMN pc_spec;