Re: Using LibPq in TAP tests via FFI

On 2024-06-17 Mo 5:07 AM, Alvaro Herrera wrote:
> On 2024-Jun-16, Andrew Dunstan wrote:
>
>
>> +sub query_oneval
>> +{
>> +    my $self = shift;
>> +    my $sql = shift;
>> +    my $missing_ok = shift; # default is not ok
>> +    my $conn = $self->{conn};
>> +    my $result = PQexec($conn, $sql);
>> +    my $ok = $result && (PQresultStatus($result) == PGRES_TUPLES_OK);
>> +    unless  ($ok)
>> +    {
>> +        PQclear($result) if $result;
>> +        return undef;
>> +    }
>> +    my $ntuples = PQntuples($result);
>> +    return undef if ($missing_ok && !$ntuples);
>> +    my $nfields = PQnfields($result);
>> +    die "$ntuples tuples != 1 or $nfields fields != 1"
>> +      if $ntuples != 1 || $nfields != 1;
>> +    my $val = PQgetvalue($result, 0, 0);
>> +    if ($val eq "")
>> +    {
>> +        $val = undef if PGgetisnull($result, 0, 0);
>> +    }
>> +    PQclear($result);
>> +    return $val;
>> +}
> Hmm, here you use PGgetisnull, is that a typo for PQgetisnull?  If it
> is, then I wonder why doesn't this fail in some obvious way?  Is this
> part dead code maybe?


It's not dead, just not exercised ATM. I should maybe include a test 
scripts for the two new modules.

As you rightly suggest, it's a typo. If it had been called it would have 
aborted the test.


>
>> +# return tuples like psql's -A -t mode.
>> +
>> +sub query_tuples
>> +{
>> +    my $self = shift;
>> +    my @results;
>> +    foreach my $sql (@_)
>> +    {
>> +        my $res = $self->query($sql);
>> +        # join will render undef as an empty string here
>> +        no warnings qw(uninitialized);
>> +        my @tuples = map { join('|', @$_); } @{$res->{rows}};
>> +        push(@results, join("\n",@tuples));
>> +    }
>> +    return join("\n",@results);
>> +}
> You made this function join the tuples from multiple queries together,
> but the output format doesn't show anything for queries that return
> empty.  I think this strategy doesn't cater for the case of comparing
> results from multiple queries very well, because it might lead to sets
> of queries that return empty result for different queries reported as
> identical when they aren't.  Maybe add a separator line between the
> results from each query, when there's more than one?  (Perhaps just
> "join('--\n', @results)" in that last line does the trick?)
>

psql doesn't do that, and this is designed to mimic psql's behaviour. We 
could change that of course. I suspect none of the uses expect empty 
resultsets, so it's probably somewhat moot.


Thanks for looking.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com