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 <cr...@2ndquadrant.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@postgresql.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.
