On Thu, Feb 2, 2012 at 8:31 PM, Joachim Wieland <joe@mcknight.de> wrote:
> On Wed, Feb 1, 2012 at 12:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think we're more-or-less proposing to rename "Archive" to
>> "Connection", aren't we?
>>
>> And then ArchiveHandle can store all the things that aren't related to
>> a specific connection.
>
> How about something like that:
> (Hopefully you'll come up with better names...)
>
> StateHandle {
> Connection
> Schema
> Archive
> Methods
> union {
> DumpOptions
> RestoreOptions
> }
> }
>
> Dumping would mean to do:
>
> Connection -> Schema -> Archive using DumpOptions through the
> specified Methods
>
> Restore:
>
> Archive -> Schema -> Connection using RestoreOptions through the
> specified Methods
>
> Dumping from one database and restoring into another one would be two
> StateHandles with different Connections, Archive == NULL, Schema
> pointing to the same Schema, Methods most likely also pointing to the
> same function pointer table and each with different Options in the
> union of course.
>
> Granted, you could say that above I've only grouped the elements of
> the ArchiveHandle, but I don't really see that breaking it up into
> several objects makes it any better or easier. There could be some
> accessor functions to hide the details of the whole object to the
> different consumers.
I'm not sure I understand what the various structures would contain.
My gut feeling for how to begin grinding through this is to go through
and do the following:
1. Rename Archive to Connection.
2. Add a PGconn object to it.
3. Change the declaration inside ArchiveHandle from "Archive public"
to "Connection source_connection".
I think that'd get us significantly closer to sanity and be pretty
simple to understand, and then we can take additional passes over it
until we're happy with what we've got.
If you're OK with that much I'll go do it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
