Bruce Momjian wrote:
> Jan Wieck wrote:
> > On 6/3/2010 4:04 PM, Bruce Momjian wrote:
> > > If you want to fork Postgres and add it, go ahead, but if the community
> > > has to maintain the code and document it, we care.
> >
> > That comment was rather unprofessional. I think the rest of us still try
> > to find the best solution for the problem, not kill the discussion. You
> > may want to rejoin that effort.
> >
> > I care about an efficient, low overhead way to get a certain
> > information, that is otherwise extremely difficult, expensive and
> > version dependent to get.
> >
> > I care about cleaning up more of the mistakes, made in the original
> > development of Slony. Namely using hacks and kluges to implement
> > details, not supported by a current version of PostgreSQL. Londiste and
> > Slony made a good leap on that with the txid data type. Slony made
> > another step like that with 2.0, switching to the (for that very purpose
> > developed and contributed) native trigger configuration instead of
> > hacking system catalogs. This would be another step in that direction
> > and we would be able to unify Londiste's and Slony's transport mechanism
> > and eliminating the tick/sync kluge.
> >
> > Care to explain what exactly you care about?
>
> Here is what I was replying to:
>
> > >> I actually have a hard time understanding why people are so opposed t$
> > > >> feature that has zero impact at all unless a DBA actually turns in ON.
> > >> What is the problem with exposing the commit order of transactions?
>
> Jan's comment is why should others care what he wants because it has
> zero impact? I am saying the community cares because we have to
> maintain the code. I stand by my comment.
>
> I remember a dismissive comment by Jan when 'session_replication_role'
> was added, and a similar strong comment from me at that time as well.
> It seems we are doing this again.
Of course, if I am misintepreting what Jan said, please let me know.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ None of us is going to be here forever. +
