[BUG] PostgreSQL Import fails with Syntax Error on valid pg_dump files

[Gautam-Bharadwaj]

---

#PR - #852 (Bug fixing)

---

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:

1. Generate a dump file from a PostgreSQL database using pg_dump (or use a SQL file containing SET commands or comments).
2. Open DrawDB and click File > Import SQL.
3. Paste the SQL content or upload the file.
4. 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.

[1ilit]

can u attach the sql

[Gautam-Bharadwaj]

@1ilit

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.5
SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_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_owner

CREATE SCHEMA public;

-- Name: users; Type: TABLE; Schema: public; Owner: postgres

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()
);

-- Name: users_id_seq; Type: SEQUENCE; Schema: public; Owner: postgres

CREATE SEQUENCE public.users_id_seq
    AS integer
    START WITH 1
    INCREMENT BY 1
    NO MINVALUE
    NO MAXVALUE
    CACHE 1;

ALTER SEQUENCE public.users_id_seq OWNED BY public.users.id;

[Gautam-Bharadwaj]

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]

@1ilit Please review my pr