Re: Some questions on the backup window

On Wed, Dec 9, 2009 at 1:19 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> hi,
>
> Just before going back to work (OK, I'm already late), I have some questions
> regarding the patch I'm currently working on.
>
> I'm working on the backup window. It's already resizable, but components on
> the first tab do not resize accordingly. Moreover, there are plenty more
> options on this window than what the UI shows.

Cool.

> I already changed the UI so that the resize works. I added two new options
> (encoding and compress ratio). All of this is available here:
> http://git.postgresql.org/gitweb?p=users/gleu/pgadmin.git;a=shortlog;h=refs/heads/pgdump.
> There are five more options interesting to add. But that's too much for one
> tab only. I'm thinking about adding a new tab. I'll split the checkboxes in
> two different tabs. Any objections on this?

Nope.

You might also want to think about how we could re-design the
oft-complained about buttons for go/close that change meaning when the
backup completes successfully.

> I would also like to add the capacity to choose the objects you want to save.
> I mean, right now, a user can save a whole database, a whole schema or one
> table. But the same user cannot save two tables on the same file with
> pgAdmin's UI. So, I intend to add another new tab, which will show all objects
> available in the selected object (all schemas and tables if he selected a
> database, all tables if he selected a schema, nothing if he selected a table).
> H'll be able to select each object he want with checkboxes. Any opinions on
> this? or maybe better ideas, because I'm not really fond of mine.

It sounds similar to what we have in the grant wizard. For
consistency, I'd say both lists should look the same, but feel free to
find a nicer presentation for both dialogues if you like (not sure I
can think of one).

> Last question. Some command line options depend on the version of pg_dump. I
> can say that the backup UI will launch the pg_dump we give with the installer,
> but we know that some users replace their copy of pg_dump so that they can
> dump and restore with older PostgreSQL release. I see two possible solutions.
> First one is to launch "pg_dump -V" to know the release of pg_dump. I find it
> a bit awkward but it'll certainly work.

That's really the only way.

> Second one is to provide a UI to
> handle different versions of pg_dump. Way better, but way more work. And
> AFAIR, it was already rejected. Before trying to find how to do solution 2 in
> a good way, do you have any opinions on which solution is best?

It was rejected by me mainly because there was no nice way of handling
it that I could picture - potentially there are nearly 15 different
versions of apps to deal with (8.0 - 8.4 of PG, EDB and GP). In
reality it's a little lower, but still... If you can come up with a
solution, I'd be happy to see it.

We'd need to have a way for us to ship one version, which might be
chosen as the default and used if the user chooses the version
override warning. We'd then need to provide a way for the user to
specify paths for other versions versions/servers that will be used
when they match the server.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com