Re: Proposal: Commit timestamp

On 2/9/2007 3:25 PM, Andrew Dunstan wrote:
> Richard Troy wrote:
>> On Fri, 9 Feb 2007, Andrew Dunstan wrote:
>>
>>> Richard Troy wrote:
>>>
>>>> In more specific terms, and I'm just brainstorming in public here, perhaps
>>>> we can use the power of Schemas within a database to manage such
>>>> divisions; commands which pertain to replication can/would include a
>>>> schema specifier and elements within the schema can be replicated one way
>>>> or another, at the whim of the DBA / Architect. For backwards
>>>> compatability, if a schema isn't specified, it indicates that command
>>>> pertains to the entire database.
>>>>
>>> I understand that you're just thinking aloud, but overloading namespaces
>>> in this way strikes me as awful. Applications and extensions, which are
>>> the things that have need of namespaces, should not have to care about
>>> replication. If we have to design them for replication we'll be on a
>>> fast track to nowhere IMNSHO.
>>>
>>
>> Well, Andrew, replication _is_ an application. Or, you could think of
>> replication as an extension to an application.
>
> No, I don't think of it as either. It's a utility, more an extension of
> the DBMS than of the application. You don't replicate for the sake of
> replicating.
>
>> I was under the impression
>> that_users_ decide to put tables in schema spaces based upon _user_ need,
>> and that Postgres developer's use of them for other purposes was
>> incroaching on user choices, not the other way around.
>
> That's exactly what you would be doing with this proposal, encroaching
> on what I regard as user space.

I'd never use a schema for that. Look at Slony-I. It uses a user
selectable schema for the stuff it needs to store in the database, to
keep Slony objects separate from user objects. But it organizes the user
tables in what is called sets. A set can be any combination of tables
and sequences from any number of namespaces. If I would do it again, I
would use names instead of numbers to identify sets, and I would allow
for summary sets containing groups of simple sets.

On the other issue, replication is part of the overall infrastructure
and thereby part of the solution to a business problem. Like the
hardware, database and application it solves a piece of the puzzle, none
of the other is particularly good at. It will perform better or
eventually not at all, depending on how much consideration the
distributed nature of the business model was given when the application
was designed. Applications that "happened by accident" rather than being
designed usually don't allow any kind of distribution.

And yes, there are people who replicate for the sake of it. It is the
kind of people who ask for sync multi-master no matter what their actual
problem might be, because it sounds most prestigious.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #