Re: Proposal: Commit timestamp

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Richard Troy <rtroy(at)ScienceTools(dot)com>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Markus Schiltknecht <markus(at)bluegap(dot)ch>, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, Theo Schlossnagle <jesus(at)omniti(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Jim Nasby <decibel(at)decibel(dot)org>
Subject: Re: Proposal: Commit timestamp
Date: 2007-02-09 19:23:03
Message-ID: 45CCCA17.4060604@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Troy 2007-02-09 19:27:39 Re: Proposal: Commit timestamp
Previous Message Andrew Hammond 2007-02-09 19:19:41 Re: Proposal: Commit timestamp