Re: Using LibPq in TAP tests via FFI

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Using LibPq in TAP tests via FFI
Date: 2024-06-17 12:22:06
Message-ID: d95ca7e1-14ad-4ffb-ab44-3892c1ff87a7@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2024-06-17 12:25:04 Re: Introduce XID age and inactive timeout based replication slot invalidation
Previous Message Bharath Rupireddy 2024-06-17 12:19:46 Is creating logical replication slots in template databases useful at all?