On 2024-07-18 Th 6:51 PM, Thomas Munro wrote:
On Wed, Jul 17, 2024 at 2:27 AM Andrew Dunstan wrote:
Here's the latest version of this patch. It removes all use of
background_psql(). Instead it uses libpq's async interface, which seems
to me far more robust. There is one remaining use of intera
On Wed, Jul 17, 2024 at 2:27 AM Andrew Dunstan wrote:
> Here's the latest version of this patch. It removes all use of
> background_psql(). Instead it uses libpq's async interface, which seems
> to me far more robust. There is one remaining use of interactive_psql(),
> but that's reasonable as it'
On 2024-06-17 Mo 10:01 AM, Andrew Dunstan wrote:
I agree with you that falling back on BackgroundPsql is not a terribly
satisfactory solution.
I'm somewhat doubtful we'll just agree on making FFI::Platypus a hard
dependency, but if we agree to do so...
Maybe not. If so your other sugges
On 2024-06-16 Su 6:38 PM, Andres Freund wrote:
Hi,
On 2024-06-16 17:43:05 -0400, Andrew Dunstan wrote:
On Fri, Jun 14, 2024 at 12:25 PM Andres Freund wrote:
I guess it's a question of how widely available FFI::Platypus is. I know
it's available pretty much out of the box on Strawberry Perl an
On 2024-Jun-17, Andrew Dunstan wrote:
> On 2024-06-17 Mo 5:07 AM, Alvaro Herrera wrote:
> > 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 o
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);
+
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) ==
On Mon, Jun 17, 2024 at 1:36 PM Thomas Munro wrote:
> Perhaps it's technically possible to build Python without the ctypes
> module, but I'm not sure and I don't see anywhere that describes it
> explicitly as optional.
One clue is that they used to bundle their own copy of libffi before
Python 3.
On Mon, Jun 17, 2024 at 12:34 PM Tom Lane wrote:
> Thomas Munro writes:
> > Really this is mostly about libffi, which is
> > super widely ported, and it is required by Python
>
> BTW, what form does that "requirement" take exactly? I see no
> evidence that the core python3 executable is linked t
I wrote:
> Andres Freund writes:
>> macports even has a platypus package, so that should be easy.
> Less easy if you don't want to depend on macports or homebrew.
I tried "sudo cpan install FFI::Platypus" against macOS Sonoma's
base-system perl. It seemed to compile all right, but a nontrivial
Thomas Munro writes:
> Really this is mostly about libffi, which is
> super widely ported, and it is required by Python
BTW, what form does that "requirement" take exactly? I see no
evidence that the core python3 executable is linked to libffi
on any of the machines I checked.
Andres Freund writes:
> On 2024-06-17 12:03:28 +1200, Thomas Munro wrote:
>> And then maybe Macs if Tom doesn't beat me to it.
> macports even has a platypus package, so that should be easy.
Less easy if you don't want to depend on macports or homebrew.
However, I see something a bit promising-l
Hi,
On 2024-06-17 12:03:28 +1200, Thomas Munro wrote:
> And then maybe Macs if Tom doesn't beat me to it.
macports even has a platypus package, so that should be easy.
For CI it should suffice to add p5.34-ffi-platypus to the list of packages in
macos' setup_additional_packages_script, they then
On Mon, Jun 17, 2024 at 10:57 AM Thomas Munro wrote:
> I'm personally willing to test/validate on the full set of non-Linux
> Unixen and write up the install instructions to help eg build farm
> animal owners adjust.
I created a page where we can log "works/doesn't work" and "installed
how" infor
Hi,
On 2024-06-16 19:07:49 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Jun 17, 2024 at 10:38 AM Andres Freund wrote:
> >> I'm somewhat doubtful we'll just agree on making FFI::Platypus a hard
> >> dependency, but if we agree to do so...
>
> > Why can't we just do that? I mean, do
Thomas Munro writes:
> On Mon, Jun 17, 2024 at 10:38 AM Andres Freund wrote:
>> I'm somewhat doubtful we'll just agree on making FFI::Platypus a hard
>> dependency, but if we agree to do so...
> Why can't we just do that? I mean, do we have any concrete reason to
> think that it'll block a supp
On Mon, Jun 17, 2024 at 10:38 AM Andres Freund wrote:
> before:
>
> [19:40:47.468] 135/296 postgresql:pg_amcheck / pg_amcheck/004_verify_heapam
> OK7.70s 32 subtests passed
> [19:43:40.853] 232/296 postgresql:amcheck / amcheck/001_verify_heapam
Hi,
On 2024-06-16 17:43:05 -0400, Andrew Dunstan wrote:
> On Fri, Jun 14, 2024 at 12:25 PM Andres Freund wrote:
> I guess it's a question of how widely available FFI::Platypus is. I know
> it's available pretty much out of the box on Strawberry Perl and Msys2'
> ucrt perl.
FWIW I hacked a bit on
On Fri, Jun 14, 2024 at 12:25 PM Andres Freund wrote:
> Hi,
>
> On 2024-06-14 11:11:38 -0400, Andrew Dunstan wrote:
> > On 2024-06-14 Fr 11:09, Andrew Dunstan wrote:
> > > Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
> > > LibPQ directly via FFI, and there was some suppo
On Fri, Jun 14, 2024 at 7:42 PM Thomas Munro wrote:
> On Sat, Jun 15, 2024 at 3:33 AM Robert Haas wrote:
> > I haven't reviewed the patch, but a big +1 for the idea. Not only this
> > might cut down on the resource costs of running the tests in CI, as
>
> It would be good to keep some context be
On Fri, Jun 14, 2024 at 11:40 AM Andres Freund wrote:
> Hi,
>
> On June 14, 2024 8:09:43 AM PDT, Andrew Dunstan
> wrote:
> >Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
> LibPQ directly via FFI, and there was some support from others as well.
> Attached is a very rough
On Sat, Jun 15, 2024 at 3:33 AM Robert Haas wrote:
> I haven't reviewed the patch, but a big +1 for the idea. Not only this
> might cut down on the resource costs of running the tests in CI, as
It would be good to keep some context between the threads here. For
the archives' sake, here is where
Hi,
On 2024-06-14 11:11:38 -0400, Andrew Dunstan wrote:
> On 2024-06-14 Fr 11:09, Andrew Dunstan wrote:
> > Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
> > LibPQ directly via FFI, and there was some support from others as well.
> > Attached is a very rough POC for just t
Hi,
On June 14, 2024 8:09:43 AM PDT, Andrew Dunstan wrote:
>Over at [1] Andres expressed enthusiasm for enabling TAP tests to call LibPQ
>directly via FFI, and there was some support from others as well. Attached is
>a very rough POC for just that.There are two perl modules, one which wraps
>
On Fri, Jun 14, 2024 at 11:11 AM Andrew Dunstan wrote:
> And here's the patch
I haven't reviewed the patch, but a big +1 for the idea. Not only this
might cut down on the resource costs of running the tests in CI, as
Andres has pointed out a few times, but it also could lead to much
nicer user in
On 2024-06-14 Fr 11:09, Andrew Dunstan wrote:
Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
LibPQ directly via FFI, and there was some support from others as
well. Attached is a very rough POC for just that.There are two perl
modules, one which wraps libpq (or almost a
Over at [1] Andres expressed enthusiasm for enabling TAP tests to call
LibPQ directly via FFI, and there was some support from others as well.
Attached is a very rough POC for just that.There are two perl modules,
one which wraps libpq (or almost all of it) in perl, and another which
uses that
27 matches
Mail list logo
