-- 089_listings_geo_precision.sql
-- Issue #769 Part E (finding #17) — geo_precision flag for city-centroid geocodes.
--
-- Context:
--   Listings scraped from Cian/N1 with bare city addresses ("Екатеринбург (Cian)",
--   "Екатеринбург (N1)") have no house number. When geocode_missing_listings() runs
--   the geocoder against such an address, it receives a city-centroid coordinate
--   (56.838, 60.605 area) and saves it as the listing's precise lat/lon. These
--   city-centroid listings then pollute radius (ST_DWithin) analog matching in the
--   estimator — they match every address in a wide radius around the city center.
--
-- Fix:
--   Add geo_precision TEXT column. Values:
--     NULL   — not yet populated (geocoded before this migration, or coords came
--              directly from scraper without going through geocode_missing path)
--     'city' — geocoder returned a city-level/coarse result (no house-number in
--              full_address); listing is a city-centroid fallback — EXCLUDE from
--              radius analog queries.
--
-- Idempotency:
--   ALTER TABLE ... ADD COLUMN IF NOT EXISTS — safe on re-run.
--   BEGIN/COMMIT block.
--
-- Backfill note:
--   NULL rows are treated conservatively as "unknown" (not excluded from analogs)
--   to avoid removing valid listings geocoded before this migration.
--   Targeted backfill of known city-centroid addresses is a follow-up task:
--     UPDATE listings SET geo_precision = 'city'
--     WHERE address IN ('Екатеринбург (Cian)', 'Екатеринбург (N1)')
--       AND lat IS NOT NULL;
--   This can be applied by QA/ops once this migration is deployed.
--
-- Dependencies:
--   002_core_tables.sql (listings table).
--
-- Deploy order:
--   Apply after 088_scrape_schedules_seed_search_matview_refresh.sql.
--   No data loss — column is nullable, existing rows unaffected.

BEGIN;

ALTER TABLE listings ADD COLUMN IF NOT EXISTS geo_precision text;

COMMIT;
