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

2014-12-07 Thread Michael Paquier
On Fri, Oct 24, 2014 at 7:23 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-24 07:18:55 -0300, Alvaro Herrera wrote: Yeah, this patch is a lot more debatable than the other one. I have pushed the first one without changing the error message. We could just test for toc.dat and

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

2014-10-24 Thread Alvaro Herrera
Jeevan Chalke wrote: 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

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

2014-10-24 Thread Andres Freund
On 2014-10-24 07:18:55 -0300, Alvaro Herrera wrote: Jeevan Chalke wrote: 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

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

2014-10-17 Thread Jeevan Chalke
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

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

2014-10-16 Thread Craig Ringer
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