Yes, it seems I misunderstood the manpage. pg_restore will *create* SQL scripts (if dbname isn't given), it can't *use* SQL scripts.
So although I still think this represents an improvement, testing/deployment/restore pipelines in use for the database may need to be altered to accommodate it. On Fri, Sep 13, 2019 at 10:59 AM ocket 8888 <[email protected]> wrote: > AFAIK the current output format is incomprehensible to anything but > pg_restore > > On Fri, Sep 13, 2019 at 10:21 AM Jeremy Mitchell <[email protected]> > wrote: > >> If pg_restore can handle both (the current binary and your suggested plain >> sql) seamlessly then doesn't seem like a problem to me to change the >> format >> to plain SQL but i can't speak for everyone using this endpoint. is >> everyone using the endpoint's response in tandem with pg_restore? >> >> if it helps testability, i think your suggestion makes a lot of sense. >> >> jeremy >> >> On Thu, Sep 12, 2019 at 11:26 AM ocket 8888 <[email protected]> wrote: >> >> > I'm rewriting the dbdump endpoint (PR #3912) and the output format used >> by >> > Perl is a binary, compressed SQL script. It makes editing and even >> testing >> > just a bit harder than it could be. The data is still compressed for >> > transfers, but a plain SQL script is much easier for a human to analyze. >> > pg_restore can work with any format that pg_dump outputs - and it >> > automatically detects which one to use, so the user doesn't even need to >> > know, really. >> > >> > But is this a problem for anyone, for any reason? >> > >> >
