Re: Improvements and additions to COPY progress reporting

On Mon, 22 Feb 2021 at 05:49, Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Mon, Feb 22, 2021 at 12:40 AM Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> >
> > On Sat, 20 Feb 2021 at 07:09, Bharath Rupireddy
> > <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > >
> > > For COPY TO the name "source_type" column and for COPY FROM the name
> > > "destination_type" makes sense. To have a combined column name for
> > > both, how about naming that column as "io_type"?
> >
> > Thank you, that's way better! PFA what I believe is a finalized
> > patchset v9, utilizing io_type terminology instead of io_target.
>
> Thanks for the patches. I reviewed them.
>
> 0001 - I think there's a bug. See COPY TO stdout doesn't print
> io_type as "STDIO".

Fixed in attached

> 0003 - patch:
> I'm doubtful if the "bytes_total": 79 i.e. test file size will be the
> same across different platforms and file systems types, if true, then
> the below tests will not be stable. Do we also want to exclude the
> bytes_total from the output, just to be on the safer side? Thoughts?

I'm fairly certain that input files of the regression tests are
considered 'binary files' to the test framework and that contents
don't change between different architectures or OSes. I also think
that any POSIX-compliant file system would report anything but the
size of the file contents, i.e. the size of the blob that is the file,
and that is correctly reported here. Other than that, if bytes_total
wouldn't be stable, then bytes_processed wouldn't make sense either.

For STDIN / STDOUT you might also have a point (different input
methods might have different length encodings for the specified
input), but insofar that I understand the test framework and the
expected git configurations, the tests run using UTF-8 / ascii only,
with a single style of newlines[+]. Sadly, I cannot provide examples
nor outputs for other test framework settings due to my lack of
experience with running the tests with non-standard settings.

Note, I'm happy to be proven wrong here, in which case I don't
disagree, but according to my limited knowledge, these outputs should
be stable.

With regards,

Matthias van de Meent

[+] Except when explicitly configured to run using non-standard
configurations, in which case there are different expected output
values to be configured for that configuration.