Re: detect custom-format dumps in psql and emit a useful error - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: detect custom-format dumps in psql and emit a useful error
Date
Msg-id 544096E0.5020607@2ndquadrant.com
Whole thread Raw
In response to Re: New developer TODO suggestions  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: detect custom-format dumps in psql and emit a useful error
List pgsql-hackers
On 09/18/2014 05:58 PM, Andres Freund wrote:
> I don't think we need to make any discinction between psql -f mydb.dump,
> psql < mydb.dump, and whatever | psql. Just check, when noninteractively
> reading the first line in mainloop.c:MainLoop(), whether it starts with
> the magic header. That'd also trigger the warning on \i pg_restore_file,
> but that's hardly a problem.

Done, patch attached.

If psql sees that the first line begins with PGDMP it'll emit:

  The input is a PostgreSQL custom-format dump. Use the pg_restore
  command-line client to restore this dump to a database.

then discard the rest of the current input source.

>> pg_restore already knows to tell you to use psql if it sees an SQL file
>> as input. Having something similar for pg_dump would be really useful.
>
> Agreed.
>
> We could additionally write out a hint whenever a directory is fed to
> psql -f that psql can't be used to read directory type dumps.

Unlike the confusion between pg_restore and psql for custom file format
dumps I haven't seen people getting this one muddled. Perhaps directory
format dumps are just a bit more niche, or perhaps it's just more
obvious that:

psql:sometump:0: could not read from input file: Is a directory

... means psql is the wrong tool.

Still, separate patch attached. psql will now emit:

psql:blah:0: Input path is a directory. Use pg_restore to restore
directory-format database dumps.

I'm less sure that this is a worthwhile improvement than the check for
PGDMP and custom format dumps though.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [Segmentation fault] pg_dump binary-upgrade fail for type without element
Next
From: Tom Lane
Date:
Subject: Re: Superuser connect during smart shutdown