On 4/9/14 9:56 PM, Stephen Frost wrote:
> As for docs and testing, those are things we would certainly be better
> off with and may mean that this isn't able to make it into 9.4, which is
> fair, but I wouldn't toss it out solely due to that.
We have a git repo with multiple worked out code examples, ones that
have been in active testing for months now. It's private just to reduce
mistakes as things are cleared for public consumption, but I (and Mark
and Jeff here) can pull anything we like from it to submit to hackers.
There's also a test case set from Yeb Havinga he used for his review.
I expected to turn at least one of those into a Postgres regression
test. The whole thing squealed to a stop when the regression tests
Craig was working on were raising multiple serious questions. I didn't
see much sense in bundling more boring, passing tests when the ones we
already had seemed off--and no one was sure why.
Now that Tom has given some guidance on the row locking weirdness, maybe
it's time for me to start updating those into make check form. The
documentation has been in a similar holding pattern. I have lots of
resources to help document what does and doesn't work here to the
quality expected in the manual. I just need a little more confidence
about which feature set is commit worthy. The documentation that makes
sense is very different if only updatable security barrier views is
committed.
--
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/