Current State
DUMP statements (DUMP DATABASE, DUMP SCHEMA, DUMP TABLES) currently return an error for PostgreSQL dialect databases with the message:
"DUMP statements are not yet supported for PostgreSQL dialect databases"
This was implemented in PR #434 to prevent generating incorrect SQL.
Problem
The SQL export format depends on spanvalue.LiteralFormatConfig which generates Google Standard SQL literals, not PostgreSQL-compatible ones. This causes several issues:
- Literal formatting: SQL literals are formatted for Google SQL syntax, which may not be valid PostgreSQL
- Identifier quoting: Would need double quotes for PostgreSQL vs backticks for Google SQL
- Schema handling: PostgreSQL uses 'public' schema vs empty string for Google SQL
Proposed Solution
To properly support PostgreSQL dialect, we need:
- Dialect-aware literal formatting: Either enhance spanvalue to support PostgreSQL literals or implement a separate formatter
- Identifier quoting function: Already drafted but not used due to literal formatting limitation
- Schema detection: Use 'public' for PostgreSQL, empty string for Google SQL
Implementation Notes
- The infrastructure for dialect detection is already in place (
session.systemVariables.DatabaseDialect)
- The main blocker is the literal formatting which is deeply integrated with spanvalue
- This might require significant changes to the formatting layer
Related
Workaround
Users with PostgreSQL databases can use alternative export methods until this is implemented.
Current State
DUMP statements (DUMP DATABASE, DUMP SCHEMA, DUMP TABLES) currently return an error for PostgreSQL dialect databases with the message:
This was implemented in PR #434 to prevent generating incorrect SQL.
Problem
The SQL export format depends on
spanvalue.LiteralFormatConfigwhich generates Google Standard SQL literals, not PostgreSQL-compatible ones. This causes several issues:Proposed Solution
To properly support PostgreSQL dialect, we need:
Implementation Notes
session.systemVariables.DatabaseDialect)Related
Workaround
Users with PostgreSQL databases can use alternative export methods until this is implemented.