On Thu, Jun 02, 2022 at 09:48:25AM -0700, Andres Freund wrote:
> On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
>> So, this leads to something like the attached. Does that sound fine
>> to you?
>
> That looks reasonable to me. Do you want to apply it or will you?
Thanks for double-checking
Hi,
On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
> On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> > Why don't you just use src/interfaces/ instead of adding a direct
> > path to libpq?
>
> So, this leads to something like the attached. Does that sound fine
> to you?
Hi,
On 2022-05-29 10:18:50 -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not
> > > to?
> >
> > Pushed.
>
> If I'm not
On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> Why don't you just use src/interfaces/ instead of adding a direct
> path to libpq?
So, this leads to something like the attached. Does that sound fine
to you?
--
Michael
From 893ef90ce07084c4e4837205a805c590798ac115 Mon Sep 17 00:
On Sun, May 29, 2022 at 10:18:50AM -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not
> > > to?
> >
> > Pushed.
>
> If I
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
>
> Pushed.
If I'm not wrong, this isn't being run by check-world.
commit 4dc465207517c4b69a1f2b657
On 2022-04-16 Sa 10:44, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
>> Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
>> src/interfaces/libpq that I'm not planning to push for now.
> I saw that Andrew just pushed something to star
On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
> src/interfaces/libpq that I'm not planning to push for now.
I saw that Andrew just pushed something to start building this under MSVC.
In case it's of any int
Hi,
On March 1, 2022 7:44:27 AM PST, Andrew Dunstan wrote:
>
>On 2/24/22 07:19, Andrew Dunstan wrote:
>> On 2/23/22 20:52, Tom Lane wrote:
>>> Peter Eisentraut writes:
On 23.02.22 23:58, Tom Lane wrote:
> Peter Eisentraut writes:
>> libpq TAP tests should be in src/interfaces/libp
On 2/24/22 07:19, Andrew Dunstan wrote:
> On 2/23/22 20:52, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut writes:
> libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test
Hi,
On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
Pushed. Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.
Regards,
Andres
>From 61a8972
Hi,
On 2022-02-25 09:56:47 -0800, Andres Freund wrote:
> On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> > I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> > coverage, because it already doesn't build the test. Once we've ironed that
> > stuff out, we could do 0003?
Hi,
On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> coverage, because it already doesn't build the test. Once we've ironed that
> stuff out, we could do 0003?
>From what I can see in the buildfarm client, we'd not lo
On 24.02.22 16:17, Tom Lane wrote:
I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to. Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.
I wonder if there are any conventions in the Perl commun
Hi,
On 2022-02-24 17:03:33 +, Jacob Champion wrote:
> On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> > One annoying bit is that our current tap invocation infrastructure for msvc
> > won't know how to deal with that. We put the build directory containing t/
> > onto PATH, but that w
On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> One annoying bit is that our current tap invocation infrastructure for msvc
> won't know how to deal with that. We put the build directory containing t/
> onto PATH, but that won't work for test/. But we also don't want to install
> test bin
Hi,
On 2022-02-24 10:17:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> >> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> >> supporting code snippets could live in some other directory under
> >> src/inte
Andres Freund writes:
> On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
>> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
>> supporting code snippets could live in some other directory under
>> src/interfaces/libpq/, which might be called "test" or something else
Hi,
On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> supporting code snippets could live in some other directory under
> src/interfaces/libpq/, which might be called "test" or something else, not
> that important.
On 24.02.22 02:52, Tom Lane wrote:
Peter Eisentraut writes:
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code
On 2/23/22 20:52, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 23.02.22 23:58, Tom Lane wrote:
>>> Peter Eisentraut writes:
libpq TAP tests should be in src/interfaces/libpq/t/.
>>> That's failing to account for the fact that a libpq test can't
>>> really be a pure-perl TAP test; you n
Peter Eisentraut writes:
> On 23.02.22 23:58, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>> That's failing to account for the fact that a libpq test can't
>> really be a pure-perl TAP test; you need some C code to drive the
>> library.
On 23.02.22 23:58, Tom Lane wrote:
Peter Eisentraut writes:
On 23.02.22 21:30, Andres Freund wrote:
Where would we want that test to live? Right now we have the slightly odd
convention that some tap tests live in src/test/{misc,modules,...}. But
e.g. frontend binary ones are below src/bin/.
Peter Eisentraut writes:
> On 23.02.22 21:30, Andres Freund wrote:
>> Where would we want that test to live? Right now we have the slightly odd
>> convention that some tap tests live in src/test/{misc,modules,...}. But
>> e.g. frontend binary ones are below src/bin/.
> libpq TAP tests should be i
On 23.02.22 21:30, Andres Freund wrote:
hen verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.
I hope others agree?
Where would we want that
Alvaro Herrera writes:
> On 2022-Feb-23, Andres Freund wrote:
>> Separately: I don't really understand why we do the whole if USE_PGXS dance
>> in
>> src/test/modules?
> Yeah, it seems a bit silly. I'm not opposed to making these makefiles
> unconditionally do the PGXS thing -- or the non-PGXS
On 2/23/22 16:16, Andres Freund wrote:
> Hi,
>
> On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 2/23/22 15:30, Andres Freund wrote:
Perhaps we should just rename src/test/modules/libpq_pipeline to
src/test/modules/libpq and move uri-regress in there as w
On 2022-Feb-23, Andres Freund wrote:
> Separately: I don't really understand why we do the whole if USE_PGXS dance in
> src/test/modules?
Yeah, it seems a bit silly. I'm not opposed to making these makefiles
unconditionally do the PGXS thing -- or the non-PGXS thing, if that
makes it easier to b
On 2022-Feb-23, Andres Freund wrote:
> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
> another way, it seems better to convert it to a tap test.
>
> I hope others agree?
WFM.
> Perhaps we
Hi,
On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2/23/22 15:30, Andres Freund wrote:
> >> Perhaps we should just rename src/test/modules/libpq_pipeline to
> >> src/test/modules/libpq and move uri-regress in there as well?
>
> > WFM
>
> +1
Cool.
One question o
Andrew Dunstan writes:
> On 2/23/22 15:30, Andres Freund wrote:
>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>> src/test/modules/libpq and move uri-regress in there as well?
> WFM
+1
regards, tom lane
> On 23 Feb 2022, at 21:30, Andres Freund wrote:
> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
> another way, it seems better to convert it to a tap test.
>
> I hope others agree?
Many
On 2/23/22 15:30, Andres Freund wrote:
> Hi,
>
> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
> another way, it seems better to convert it to a tap test.
>
> I hope others agree?
yes
>
Hi,
When verifying that the meson port actually runs all perl based tests I came
across src/interfaces/libpq/test/regress.pl. Instead of running tests yet
another way, it seems better to convert it to a tap test.
I hope others agree?
Where would we want that test to live? Right now we have the
34 matches
Mail list logo
