Re: Proposal: Commit timestamp

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.

> Either way,
> claiming "need" like this strikes me as stuck-in-a-rut or dogmatic
> thinking. Besides, don't we have schema nesting to help resolve any such
> "care?"

No. We do now have schema nesting, for this or any other purpose. Where
did you get that idea? If we did I would not be so resistant to using
them for this purpose, but as it is, if you hijack schemas for
replication segregation you will detract from their more obvious use in
name segregation.

cheers

andrew