We have tools that use the /dbdump API for things like DB backups and DB testing. If the API output changed out beneath those things, they would 100% break. IMO the default output should remain as it is today, and if we think a new format is needed then we should just add an optional query parameter to the /dbdump endpoint. For example: /api/1.1/dbdump (uses default compressed format) /api/1.1/dbdump?format=compressed (same as default) /api/1.1/dbdump?format=sql (uses new "SQL script" output format for whatever reason)
That is, if we think we even have a valid use case for a new format. We should be careful not to add things to the API that we don't really need. Already it seems like this endpoint is very dangerous and _probably_ shouldn't exist (although it does and things depend on it now). If a test can just read the current compressed format and convert it to a sql script for analysis or whatever, that's probably better than adding support for various output formats. - Rawlin 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? > > > > >
