fix(data-warehouse): search warehouse tables by all queryable names#60424
Merged
Conversation
…e names Warehouse tables in the SQL editor sidebar were only searchable by their dotted display name (e.g. postgres.prod.invoice_with_annual), not by the raw underscore form they are also queryable by (prod_postgres_invoice_with_annual). Surface the raw name as search_aliases from the backend and add it to the sidebar's fuzzy-search keys so either form finds the table.
Contributor
|
Reviews (1): Last reviewed commit: "fix(data-warehouse): make warehouse tabl..." | Re-trigger Greptile |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR makes SQL editor sidebar warehouse table search match both the dotted display name and the raw queryable warehouse table name.
Changes:
- Adds
search_aliasesto the data warehouse table schema/model. - Populates aliases during backend database serialization when raw and display names differ.
- Includes
search_aliasesin Fuse search keys and adds backend serialization coverage.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
posthog/schema.py |
Adds optional search_aliases to warehouse table schema model. |
posthog/hogql/database/database.py |
Serializes raw warehouse table names as search aliases. |
posthog/hogql/database/test/test_database.py |
Verifies sourced warehouse tables expose raw-name aliases. |
frontend/src/scenes/data-warehouse/editor/sidebar/queryDatabaseLogic.tsx |
Adds aliases to sidebar Fuse search keys. |
frontend/src/queries/schema/schema-general.ts |
Updates generated TypeScript schema type. |
frontend/src/queries/schema.json |
Updates generated JSON schema. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
|
Size Change: 0 B Total Size: 80.7 MB ℹ️ View Unchanged
|
Contributor
|
👋 Visual changes detected for this PR. Review and approve in PostHog Visual Review If these changes are unexpected, they may be caused by a flaky test or a broken snapshot on master. Don't approve — rerun the job or wait for a fix. |
Gilbert09
approved these changes
May 29, 2026
Contributor
|
🎭 Playwright report · View test results →
These issues are not necessarily caused by your changes. |
mariusandra
approved these changes
May 29, 2026
mariusandra
approved these changes
May 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Data warehouse tables in the SQL editor sidebar were only searchable by their dotted display name (e.g.
postgres.prod.invoice_with_annual). The same table is also queryable by its raw underscore name (e.g.prod_postgres_invoice_with_annual), but searching for that form returned nothing — the segment order differs (postgres.prod.…vsprod_postgres_…), so even fuzzy matching missed it. Users couldn't find tables they knew existed and were queryable.Changes
The raw queryable name is now surfaced from the backend as
search_aliasesonDatabaseSchemaDataWarehouseTable, and the sidebar's fuzzy search includes it as a key, so a table is found by any form it's queryable under.posthog/hogql/database/database.py—serialize_databasesetssearch_aliasesto the rawwarehouse_table.namewhen it differs from the dotted key.schema-general.ts— added optionalsearch_aliases?: string[]toDatabaseSchemaDataWarehouseTable;schema.py,schema.json, and MCP generated types regenerated.queryDatabaseLogic.tsx— addedsearch_aliasesto the Fuse search keys.A frontend-only
.replace('.', '_')can't reconstruct the raw name because the source-type and prefix segments are reordered/merged differently, so the alias has to come from the backend, which knows the registered names. Direct-connection tables are unaffected: theirnamealready equals the raw name, so the alias isNone.How did you test this code?
I'm an agent. I extended an existing backend serialization test (
test_serialize_database_warehouse_table_source) to assertsearch_aliases == ["stripe_table_1"]for a Stripe source table that displays asstripe.table_1, and ran the warehouse/direct-postgres serialization suite (13 tests) — all pass. Ruff lint/format clean. I could not run a full frontend typecheck in this environment because kea-typegen artifacts aren't generated here, so unrelated logic files error; the change only adds an optional field to an interface and a Fuse key string.Publish to changelog?
no
Docs update
No docs change needed.
🤖 Agent context
Authored with Claude Code (Opus 4.7). Originated from a support thread about a Postgres warehouse table being queryable but not appearing in SQL-editor search. Traced the naming pipeline: the dotted name comes from
get_data_warehouse_table_name, while the raw underscore name is registered separately as a queryable alias inDatabase.serialize. Considered a frontend-only flatten of the dotted name but rejected it because segment order differs, so it wouldn't reproduce the raw name; surfacing the actual registered name from the backend is the correct fix. Requires human review.