Dave Page wrote:
I see what's happening. I dump things in text format more often than not, and that's what it's barfing on. I think that needs to be handled a lttle more cleanly when we release - perhaps check the file format before passing it to pg_restore,
Ok, checking the file signature seems reasonable.
and if text, just load the first hundred lines or so for inspection.
No. Advice to use Query Tool instead or sth like that.
Whilst we're on that subject, most of my backups have .sql extensions -For backup only, not restore; we don't want to offer arbitrary scripts to pg_restore.
any objection to adding that as a defaul extension in the file open
dialogue.
Well, if you insist we might enable server status on servers too :-)Finally, on a vaguely related note, I think we need to do some re-factoring of the context and tools menus. Perhaps have a copy of the tools menu as a sub menu of the context menu, rather than a seemingly random inclusion of some items. Also, when items are active could do with some though - for example, you cannot access the server status when clicking a server node(!), only a database.
I admit we should have a look at the context menu. I deliberately left backup/restore out of it, because it's not so often in use, though it belongs there.
Maybe we should *create* the context menu on-demand, instead of enabling/disabling. Disabled menus always signal "this item might be enabled under some circumstances", which is usually not true in that very context.
Regards, Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
