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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
