Re: Adding pipe support to pg_dump and pg_restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: David Hedberg <david(dot)hedberg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding pipe support to pg_dump and pg_restore
Date: 2018-09-29 15:42:40
Message-ID: 1296.1538235760@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * David Hedberg (david(dot)hedberg(at)gmail(dot)com) wrote:
>> The idea is to add a --pipe option to pg_dump / pg_restore where you
>> can specify a custom shell command that is used to write / read each
>> .dat-file. Usage examples include encryption with pgp and/or custom
>> compression pipelines. %p in the command is expanded to the path to
>> write to / read from. The pipe command is not applied to the toc.

> I would certainly think that we'd want to have support for custom format
> dumps too..

This seems like rather a kluge :-(. In the context of encrypted dumps
in particular, I see no really safe way to pass an encryption key down
to the custom command --- either you put it in the command line to be
exec'd, or you put it in the process environment, and neither of those
are secure on all platforms.

The assumption that the TOC doesn't need encryption seems pretty
shaky as well.

So I think we'd be better off proceeding as Stephen envisions.
Maybe there are use-cases for the sort of thing David is proposing,
but I don't think encrypted dumps present a good argument for it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-09-29 15:49:55 Re: Online verification of checksums
Previous Message Tom Lane 2018-09-29 15:35:47 Cygwin linking rules