Обсуждение: Re: Misc topics
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 22 June 2004 17:10 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Misc topics > > 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. Not really a good idea for say, a 300MB backup though is it? > >Whilst we're on that subject, most of my backups have .sql > extensions - > >any objection to adding that as a defaul extension in the file open > >dialogue. > > > > > For backup only, not restore; we don't want to offer > arbitrary scripts to pg_restore. Mine are not arbitrary scripts. They are backups that happen to be in plain text format, and have an appropriate .sql extension. > >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. > > > Well, if you insist we might enable server status on servers > too :-) 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. That's not a bad idea - the tools menu should remain constant of course. Regards, Dave.
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. >> >> > >Not really a good idea for say, a 300MB backup though is it? > > So why don't you use tar or compressed format? The Restore Tool is a frontend for pg_restore, which can't handle plain. Anyway, with file signature checking there will be just a message "incompatible format" or so. > > >>>Whilst we're on that subject, most of my backups have .sql >>> >>> >>extensions - >> >> >>>any objection to adding that as a defaul extension in the file open >>>dialogue. >>> >>> >>> >>> >>For backup only, not restore; we don't want to offer >>arbitrary scripts to pg_restore. >> >> > >Mine are not arbitrary scripts. They are backups that happen to be in >plain text format, and have an appropriate .sql extension. > > I understand, I'd simply not recommend to use plain for backup purposes. It has many disadvantages. I'd recommend plain dump only if you'd need to edit the dump, i.e. if it's *not* meant for backup/restore purposes. >>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. >> >> > >That's not a bad idea - the tools menu should remain constant of course. > > Agreed, context menu only. Todo. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 22 June 2004 20:39 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Misc topics > > > So why don't you use tar or compressed format? The Restore > Tool is a frontend for pg_restore, which can't handle plain. > Anyway, with file signature checking there will be just a > message "incompatible format" or so. Been doing it that way since 6.3 (before pg_restore existed iirc). I keep doing it that way because there are no real space issues for me, and if I ever need to restore a system from backup, I can upgrade at the same time and still be able to massage the dump file into the new version of PostgreSQL if required. I think the easy answer is to just assume the file is a text dump if a signature cannot be found, and just pipe it to psql (so we don't have to worry about handling \connect or \copy ourselves). > > I understand, I'd simply not recommend to use plain for > backup purposes. > It has many disadvantages. And some advantages. > I'd recommend plain dump only if you'd need to edit the dump, > i.e. if it's *not* meant for backup/restore purposes. I always assume the worst (as one should with backups IMO) - that something will go wrong and I may need to massage the data for some reason. The bottom line is, whatever view you take, plain text backups can be done and are done - thus we should try to support them. Regards, Dave
Dave Page wrote: > > >Been doing it that way since 6.3 (before pg_restore existed iirc). I >keep doing it that way because there are no real space issues for me, >and if I ever need to restore a system from backup, I can upgrade at the >same time and still be able to massage the dump file into the new >version of PostgreSQL if required. I think the easy answer is to just >assume the file is a text dump if a signature cannot be found, and just >pipe it to psql (so we don't have to worry about handling \connect or >\copy ourselves). > > I really want to leave this to experts, calling psql themselves. Implementing plain restore suggests it as an equivalent alternative, which it is not. Backup/Restore tools are for easy and safe support of standard backup situations, i.e. if I hit "backup" I assume the resulting file to include anything I might need later. Additionally, a restore selection should be available. We have this only with compressed and tar, not plain. As you already mentioned, plain is for special purposes reworking the output (do it on your own risk, if you know really what you do) or for ancient backward compatibility. >And some advantages. > > To say it with different words: pg_dump has two modes: one creating backup files (compressed/tar), the other extraction of data for later manipulation. That's certainly not paired with pg_restore. I'm beginning to think about splitting these two tasks into two separate tools. >I always assume the worst (as one should with backups IMO) - that >something will go wrong and I may need to massage the data for some >reason. > > If you need to massage the file, you'll take an editor for that. I'd recommend the Query Tool.... >The bottom line is, whatever view you take, plain text backups can be >done and are done - thus we should try to support them. > > I refuse to name that pg_dump plain thing a backup. It's a data extraction, object to manipulation. BTW, I'm waiting for PITR, which will offer the backup type that I *really* want. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 22 June 2004 22:02 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Misc topics > > > I really want to leave this to experts, calling psql themselves. > Implementing plain restore suggests it as an equivalent > alternative, which it is not. > > Backup/Restore tools are for easy and safe support of > standard backup situations, i.e. if I hit "backup" I assume > the resulting file to include anything I might need later. > Additionally, a restore selection should be available. We > have this only with compressed and tar, not plain. As you > already mentioned, plain is for special purposes reworking > the output (do it on your own risk, if you know really what > you do) or for ancient backward compatibility. So what you are saying is that pgAdmin will not include options to support more advanced users? > To say it with different words: > pg_dump has two modes: one creating backup files > (compressed/tar), the other extraction of data for later > manipulation. That's certainly not paired with pg_restore. > I'm beginning to think about splitting these two tasks into > two separate tools. > > I refuse to name that pg_dump plain thing a backup. It's a > data extraction, object to manipulation. You already did call it a backup when you put 'plain' and a bunch of related options on frmBackup. Currently we're in the worst case scenario - you have a bunch of backup options that'll create files that cannot be restored using the restore tool! Can we get some other opinions on this - should backup/restore include the ability to use plain text format files? > BTW, I'm waiting for PITR, which will offer the backup type that I > *really* want. Yeah, well, we're all waiting for that :-) /D