You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] PostgreSQL Import fails with Syntax Error on valid pg_dump files #852
Describe the bug
When importing a SQL script generated by pg_dump (PostgreSQL), the application fails to generate the diagram and displays a "Syntax Error" message. This happens even for valid SQL files because the parser (node-sql-parser) crashes when it encounters standard PostgreSQL dump artefacts like comments (--), configuration commands (SET statement_timeout...), or extensions (CREATE EXTENSION).
To Reproduce
Steps to reproduce the behaviour:
Generate a dump file from a PostgreSQL database using pg_dump (or use a SQL file containing SET commands or comments).
Open DrawDB and click File > Import SQL.
Paste the SQL content or upload the file.
See error: "Syntax Error due to token..." (or generally failing to load).
Expected behaviour
The application should successfully parse the DDL statements (CREATE TABLE, ALTER TABLE) to generate the diagram, while ignoring non-structural metadata like comments or session variable configurations.
Desktop (please complete the following information):
OS: macOS / Windows / Linux (Platform Independent)
Browser Chrome / Firefox / Safari
Additional context
The issue stems from the strictness of the node-sql-parser library. It does not support specific pg_dump meta-commands. A fix involves sanitising the SQL input to strip these artefacts before parsing. I have prepared a PR for this.
Sure! Here is a minimal reproduction snippet that fails on the current version but passes with my fix. It contains standard pg_dump artefacts like SET commands and comments.
-- Dumped by pg_dump version 14.5SET statement_timeout =0;
SET lock_timeout =0;
SET idle_in_transaction_session_timeout =0;
SET client_encoding ='UTF8';
SET standard_conforming_strings =on;
SELECTpg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;
-- Name: public; Type: SCHEMA; Schema: -; Owner: pg_database_ownerCREATESCHEMApublic;
-- Name: users; Type: TABLE; Schema: public; Owner: postgresCREATETABLEpublic.users (
id integerNOT NULL,
username character varying(255) NOT NULL,
email character varying(255) NOT NULL,
created_at timestamp without time zone DEFAULT now()
);
-- Name: users_id_seq; Type: SEQUENCE; Schema: public; Owner: postgresCREATESEQUENCEpublic.users_id_seq
ASinteger
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTERSEQUENCEpublic.users_id_seq OWNED BY public.users.id;
After the fix (How it is processed): The sanitizeSQL function added in this PR strips the noise (comments, SET, SELECT pg_catalog) internally. The parser receives this clean input, which it accepts without error:
CREATE SCHEMA public;
CREATE TABLE public.users (
id integer NOT NULL,
username character varying(255) NOT NULL,
email character varying(255) NOT NULL,
created_at timestamp without time zone DEFAULT now()
);
Activity
1ilit commentedon Jan 28, 2026
can u attach the sql
Gautam-Bharadwaj commentedon Jan 28, 2026
@1ilit
Sure! Here is a minimal reproduction snippet that fails on the current version but passes with my fix. It contains standard
pg_dumpartefacts likeSETcommands and comments.Gautam-Bharadwaj commentedon Jan 28, 2026
After the fix (How it is processed): The sanitizeSQL function added in this PR strips the noise (comments, SET, SELECT pg_catalog) internally. The parser receives this clean input, which it accepts without error:
CREATE SCHEMA public;
CREATE TABLE public.users (
id integer NOT NULL,
username character varying(255) NOT NULL,
email character varying(255) NOT NULL,
created_at timestamp without time zone DEFAULT now()
);
Gautam-Bharadwaj commentedon Apr 2, 2026
@1ilit Please review my pr