This functionality is duplicative with BACKUP and RESTORE, though they use more reliable, native representations for data and metadata. Ensuring all new SQL features like types, schemas, etc all work correctly in dump adds significant overhead to that feature work, or in the past is often missed, leading dump to be incomplete or broken. Previously we maintained both BACKUP and dump as BACKUP was enterprise-only but in 20.2+ basic backup that can do at least as much as dump can is free so this is no longer a reason to keep dump.
Interoperability with other databases is also not a reason to keep dump around -- dump already does not produce data that can be directly loaded into another database so a more reliable migration would be to export to a vendor-neutral format like CSV and use the native loading facilities of the destination DB. If maintaining dump to keep up with just out own feature set has proven too expensive, keeping up with it against a foreign DB would be doubly so.
This functionality is duplicative with BACKUP and RESTORE, though they use more reliable, native representations for data and metadata. Ensuring all new SQL features like types, schemas, etc all work correctly in
dumpadds significant overhead to that feature work, or in the past is often missed, leading dump to be incomplete or broken. Previously we maintained both BACKUP and dump as BACKUP was enterprise-only but in 20.2+ basic backup that can do at least as much as dump can is free so this is no longer a reason to keep dump.Interoperability with other databases is also not a reason to keep
dumparound -- dump already does not produce data that can be directly loaded into another database so a more reliable migration would be to export to a vendor-neutral format like CSV and use the native loading facilities of the destination DB. If maintaining dump to keep up with just out own feature set has proven too expensive, keeping up with it against a foreign DB would be doubly so.