"Joshua D. Drake" <jd@commandprompt.com> writes:
> Gregory Stark <stark@enterprisedb.com> wrote:
>> Putting it in core or contrib means that when we change the snapshot
>> mechanics in 8.4 the same developer will be able to fix the module at
>> the same time (and find out if his changes break it at the same
>> time).
> Which is very cool, for *8.4* :)
I think you missed one point: waiting for 8.4 is too late because of the
mechanics of the slony/skytools projects. The reason this came up at
all is those projects' recognition that they had a narrow window to
standardize on a common bit of code. Slony is breaking backward
compatibility for 8.3 in order to make use of the new backend
ENABLE/DISABLE REPLICA TRIGGER functionality. They can fold in
dependence on an externally-supplied txid at the same time, but if they
miss doing so, they're hardly likely to break compatibility again
anytime in the near future. So if there's no solution available for 8.3
then there's no point in doing anything at all.
This is not an argument why they cannot depend on a pgfoundry project
for 8.3 instead of a contrib module, but it is the reason why simply
waiting to propose the feature for 8.4 wasn't a viable alternative.
I had been thinking that the choice between pgfoundry and contrib
was technically neutral and only a matter of policy, but Greg's
argument does raise a valid technical point: if the code is in contrib
then it *will* track any redesign of the snapshot maintenance code,
whereas if it's in pgfoundry then it won't. That could perhaps be
addressed by merging it into 8.4 before anyone does any snapshot fixing,
but our track record on causing such things to happen in a particular
sequence isn't great ...
regards, tom lane