-- v_hashtag_counts: apply the same visibility rules as v_feed.
--
-- The chip row and the grid's tag picker are both fed by this view, but it has only ever
-- filtered `u.deleted_at IS NULL`. Migration 011 added ban/hide filtering to the feed and
-- never reached here, so the two disagreed about which uploads exist:
--
--   * A host bans a guest who posted 3 of the 12 `#tanz` photos. The chip keeps reading
--     "#tanz 12"; tapping it returns 9. The count is presented as authoritative and is not.
--   * A tag used ONLY by a banned or hidden guest stays in the chip row and in the tag
--     picker as a selectable option that leads to an empty feed — a ghost filter that
--     cannot be cleared because there is nothing wrong with it to see.
--
-- Bans are exactly the moment a host is watching these numbers to confirm the moderation
-- took effect, so a stale count reads as "the ban didn't work".
--
-- Same predicate as v_feed (see 016_display_derivative.up.sql), joined through `user`.
DROP VIEW IF EXISTS v_hashtag_counts;

CREATE VIEW v_hashtag_counts AS
SELECT
    h.event_id,
    h.tag,
    COUNT(uh.upload_id) AS upload_count
FROM hashtag h
JOIN upload_hashtag uh ON uh.hashtag_id = h.id
JOIN upload u          ON u.id = uh.upload_id AND u.deleted_at IS NULL
JOIN "user" usr        ON usr.id = u.user_id
WHERE usr.uploads_hidden = FALSE
  AND usr.is_banned = FALSE
GROUP BY h.event_id, h.id, h.tag
ORDER BY upload_count DESC;
