Paul Ramsey <pramsey@cleverelephant.ca> writes:
>> On Feb 20, 2019, at 10:37 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> If we add one set of code now and need to add another different one later, we will have 2 sets of code that do
similarthings.
> Note that adding an iterator isn’t adding two ways to do the same thing,
> since the iterator would slot nicely underneath the existing slicing
> API, and just iterate to the requested slice size. So this is easily
> just “another step” along the train line to providing streaming access
> to compressed and TOASTed data.
Yeah, I find Paul's argument fairly convincing there. There wouldn't be
much code duplication, and for the places that can use it, a "fetch the
first N bytes" API is probably going to be more natural and easier to
use than an iteration-based API. So we'd likely want to keep it, even
if it ultimately becomes just a thin wrapper over the iterator.
I've not reviewed the patch, but as far as the proposed functionality
goes, it seems fine to accept this rather than waiting for something
much more difficult to happen.
regards, tom lane
