Le 5 décembre 2011 17:30, Christopher Browne <cbbrowne at afilias.info> a écrit :
> On Mon, Dec 5, 2011 at 9:28 AM, Cédric Villemain
> <cedric.villemain.debian at gmail.com> wrote:
>> Le 5 décembre 2011 10:12, Laura Passigni <passigni at navionics.it> a écrit :
>>> Dear all,
>>>
>>> I’m using slony to have a replica of my database (Postgresql 8.4).
>>>
>>> Currently I replicate only some tables, not the entire database. I was
>>> wondering if it is possible to replicate only some records of a table, for
>>> example according to some field’s value. In other words, perform a sort of
>>> conditional replica.
>>
>> It is not in the features list of slony.
>> I don't think it is possible without rewriting triggers. Maybe have a
>> look at logtrigger().
>
> It ought to become plausible after 2.2 is released.
>
> We have the change (still being integrated in; I think Jan is planning
> to get this into master this week; you can take a peek at the repos
> for Jan/Steve/Myself at GitHub to see what things are looking like)
> that the log data is being split apart rather differently, notably so
> that the log data is no longer "cooked" into text, but is, instead,
> kept as a series of arrays.
>
> That should make it possible to inject a "hook" function into the log
> application function to reinterpret what is to be done with the log
> data.
>
> The first aspect that we expect to be pretty easy is to replay data
> into a different table/schema; that's extremely useful for the case
> where people want to replicate several instances of an application
> into a "consolidation database."  This just involves renaming the
> target table, and I wouldn't expect this to be terribly difficult to
> deal with.  It should be able to be handled pretty cleanly.
> (Hopefully.)
>
> But as a broader matter, it would be interesting to add in "hooks" to
> do more sophisticated things such as:
>
> - Renaming columns.  Describing the configuration well is likely to be
> the hard part.
>
> - Selective replication, based on interpreting the data that is
> provided.  Given a "hook" function to override the built-in behaviour,
> it should surely be possible to do "just about anything."  Though the
> higher the flights of fancy, the wiser this likely isn't...
>
> Rewriting the triggers, as they exist now, seems horribly unattractive
> to me.  They're SPI C functions, and there's enough intricacy there
> that I'd think it pretty dangerous to hack on them without a pretty
> deep understanding of them.  But this changes in 2.2...

Sure! Andrew' solution is way better at the moment.
Very nice features are planned, good to hear.
-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation