Re: detect custom-format dumps in psql and emit a useful error

Hi,

Regarding Loading Custom Format Dump:
===
When we supply plain sql file to pg_restore, we get following error:
$ ./install/bin/pg_restore a.sql
pg_restore: [archiver] input file does not appear to be a valid archive

So I would expect similar kind of message when we provide non-plain sql
file to psql. Something like:
"input file does not appear to be a valid sql script file
(use pg_restore instead)"

I have added additional details in parenthesis as we correctly identified
it as a custom dump file and user wanted it to restore.

However I do not see any issue with the patch.

Regarding Directory Error:
===
I strongly against the proposal. This patch changing error message to
something like this:
"psql:blah:0: Input path is a directory. Use pg_restore to restore
directory-format database dumps."

So even though I accidentally provide a directory instead of a sql script
file when I have NO intention of restoring a dump, above message looks
weired. Instead current message looks perfectly fine here. i.e.
"could not read from input file: Is a directory"

psql always expect a file and NOT directory. Also it is not necessarily
working on restoring a dump.

Thanks

On Fri, Oct 17, 2014 at 9:41 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> 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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 30589500

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.