Re: Skytools committed without hackers discussion/review

On 10/10/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Wed, Oct 10, 2007 at 03:27:17PM +0300, Marko Kreen wrote:
> >> Now txid can change that. E.g. in Skype, it has become irreplaceable
> >> tool for coordinating work between several databases. Here we are
> >> probably going overboard with usage of queues...
>
> > If it is this irreplacable killer feature, it should *not* be in contrib.
> > It should be in the core backend, and we should be discussing if we can
> > bend the rules for that.
>
> It may be a killer feature for Skytools and Slony, but even so that's a
> small part of our userbase. I see nothing wrong with having it in
> contrib now with an eye to migrating to the core later, when and if we
> see there's enough demand for that. Another reason for that approach
> is that once it's in core it will be very much harder to make any tweaks
> to the API; and with the prospective uses being largely unwritten as
> yet, it hardly seems unlikely we might not want some changes.

Considering the core operations are now being in active use
some 6-7 years, I really fail to see how there can be anything
to tweak, unless you are speaking changing naming style.

IMHO the core operations are already as stable as PostgreSQL use
of MVCC, as the module just exports backend internal state...
Current set of functions is the minimal necessary to implement
queue operations, there is nothing more to remove.

We might want to add some helper functions for query generation,
but that does not affect core operation.

Another thing can can be done is more compact representation for
txid_snapshot type, but that also won't affect core operation.

I am very happy for txid being in contrib, I'm not arguing against
that, but the hint that txid module is something that just freshly
popped out of thin air is irking me.

> I think our two realistic options today are (1) leave the code where
> it is, or (2) remove it. While Jan clearly failed to follow the agreed
> procedures, I'm not convinced the transgression was severe enough to
> justify (2).

Thanks for being understanding.

--
marko