On Fri, Jun 14, 2024 at 8:49 AM Tom Lane wrote:
> I think that's an oversimplified analysis. Sure, the languages are
> both Turing-complete, but for our purposes here they are both simply
> glue languages around some set of testing facilities. Some of those
> facilities will be provided by the b
(slowly catching up from the weekend email backlog)
On Fri, Jun 14, 2024 at 5:10 AM Robert Haas wrote:
> I mean, both Perl and Python are Turing-complete.
Tom responded to this better than I could have, but I don't think this
is a helpful statement. In fact I opened the unconference session with
On 2024-06-17 Mo 4:27 AM, Matthias van de Meent wrote:
Hi Greg, Jelte,
On Sat, 15 Jun 2024 at 23:53, Greg Sabino Mullane
wrote:
> Those young-uns are also the same group who hold their nose when
coding in C, and are always clamoring for rewriting Postgres in Rust.
Could you point me to
On Sun, 16 Jun 2024 at 23:04, Robert Haas wrote:
>
> On Sat, Jun 15, 2024 at 6:00 PM Melanie Plageman
> wrote:
> > Writing a new test framework in a popular language that makes it more
> > likely that more people will write more tests and test infrastructure
> > is such a completely different thi
Hi Jacob,
> For the v18 cycle, I would like to try to get pytest [1] in as a
> supported test driver, in addition to the current offerings.
>
> (I'm tempted to end the email there.)
Huge +1 from me and many thanks for working on this.
Two cents from me.
I spent a fair part of my career writing
Hi Greg, Jelte,
On Sat, 15 Jun 2024 at 23:53, Greg Sabino Mullane
wrote:
>
> On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio
wrote:
>>
>> Afaict, there's a significant part of our current community who feel the
same way (and I'm pretty sure every sub-30 year old person who
>> newly joins the
On Sat, Jun 15, 2024 at 6:00 PM Melanie Plageman
wrote:
> > Those young-uns are also the same group who hold their nose when coding in
> > C, and are always clamoring for rewriting Postgres in Rust. And before
> > that, C++. And next year, some other popular language that is clearly
> > better
On Sat, Jun 15, 2024 at 5:53 PM Greg Sabino Mullane wrote:
>
> On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio wrote:
>>
>> Afaict, there's a significant part of our current community who feel the
>> same way (and I'm pretty sure every sub-30 year old person who
>> newly joins the community w
On Fri, Jun 14, 2024 at 5:09 PM Jelte Fennema-Nio
wrote:
> Test::More on the other hand, while indeed still maintained, it's
> definitely not getting significant new feature development or
> improvements[2]. Especially when comparing it to pytest[3].
>
That's fair, although it's a little hard to
On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio
wrote:
> Afaict, there's a significant part of our current community who feel the
> same way (and I'm pretty sure every sub-30 year old person who
> newly joins the community would feel the exact same way too).
>
Those young-uns are also the sam
On Sat, 15 Jun 2024 at 19:27, Robert Haas wrote:
> This surprises me. I agree that the current state of affairs is kind
> of annoying, but the contents of regress_log_whatever are usually
> quite long. Printing all of that out to standard output seems like
> it's just going to flood the terminal w
Hi,
On 2024-06-15 10:45:16 -0400, Andrew Dunstan wrote:
> > 4. Pytest has autodiscovery of test files and functions, so we
> > probably wouldn't have to specify all of the exact test files anymore
> > in the meson.build files.
>
>
> I find this comment a bit ironic. We don't need to do that with
On Sat, Jun 15, 2024 at 12:48 PM Jelte Fennema-Nio wrote:
> Honestly, my primary *objective* complaint about our current test
> suite, is that when a test fails, it's very often impossible for me to
> understand why the test failed, by only looking at the output of
> "meson test". I think logging
On Sat, 15 Jun 2024 at 16:45, Andrew Dunstan wrote:
> I see the fact that we stash the output in a file as a feature. Without
> it, capturing failure information in the buildfarm client would be more
> difficult, especially if there are multiple failures. So this is
> actually something I think we
On 2024-06-14 Fr 18:11, Jelte Fennema-Nio wrote:
On Fri, 14 Jun 2024 at 17:49, Tom Lane wrote:
But what I'd really like to see is some comparison of the
language-provided testing facilities that we're proposing
to depend on. Why is pytest (or whatever) better than Test::More?
Some advantage
On Fri, 14 Jun 2024 at 17:49, Tom Lane wrote:
> But what I'd really like to see is some comparison of the
> language-provided testing facilities that we're proposing
> to depend on. Why is pytest (or whatever) better than Test::More?
Some advantages of pytest over Test::More:
1. It's much easie
On Fri, Jun 14, 2024 at 9:24 AM Robert Haas wrote:
> For example, the fact that
> nobody's helping Thomas maintain this cfbot that we all have come to
> rely on, or helping him get that integrated into
> commitfest.postgresql.org, is a problem.
I've been talking to Magnus and Jelte about cfbot an
On Fri, 14 Jun 2024 at 22:33, Greg Sabino Mullane wrote:
> I am not happy with the state of Perl, as it has made some MAJOR missteps
> along the way, particularly in the last 5 years. But can we dispel this
> strawman? There is a difference between "unpopular" and "unmaintained". The
> latest v
On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio
wrote:
> But Perl is at the next level of unmaintained infrastructure. It is
> actually clear how you can contribute to it, but still no new
> community members actually want to contribute to it. Also, it's not
> only unmaintained by us but it's a
On 2024-06-14 09:11:11 -0700, Andres Freund wrote:
> On 2024-06-14 11:49:29 -0400, Tom Lane wrote:
> > Am I right in guessing that pytest will have nothing to do with that?
>
> Looks like there's a plugin for pytest to support tap as output:
> https://pypi.org/project/pytest-tap/
>
> However, it'
Hi,
On 2024-06-14 11:49:29 -0400, Tom Lane wrote:
> I also wonder about integration of python-based testing with what
> we already have. A significant part of what you called the meson
> work had to do with persuading pg_regress, isolationtester, etc
> to output test results in the common format
Robert Haas writes:
> I mean, both Perl and Python are Turing-complete. Anything you can do
> in one, you can do in the other, especially when you consider that
> we're not likely to accept too many dependencies on external Perl or
> Python modules. That's why I see this as nothing more or less th
On 2024-06-14 Fr 08:10, Robert Haas wrote:
We've talked about a libpq FFI interface, but it hasn't been done;
Hold my beer :-)
I just posted a POC for that.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On Thu, Jun 13, 2024 at 8:12 PM Jacob Champion
wrote:
> But also: do you have opinions on what to fill in as steps 2
> (something we have no ability to test today) and 3 (something we do
> test today, but hate)?
>
> My vote for step 2 is "client and server separation", perhaps by
> testing libpq f
On Thu, Jun 13, 2024 at 1:27 PM Robert Haas wrote:
>
> On Thu, Jun 13, 2024 at 4:06 PM Jacob Champion
> wrote:
> > There was a four-step plan sketch at the end of that email, titled "A
> > Plan". That was not intended to be "the final detailed plan", because
> > I was soliciting feedback on the e
On Thu, Jun 13, 2024 at 1:04 PM Robert Haas wrote:
> One caveat here,
> perhaps, is that the focus of the work you've done up until now and
> the things that I and other community members may want as a condition
> of merging stuff may be somewhat distinct. You will have naturally
> been focused on
On Thu, 13 Jun 2024 at 23:35, Andrew Dunstan wrote:
> Clearly there are areas we can improve, and we need to be somewhat more
> proactive about it.
To follow that great suggestion, I updated meson wiki[1] after I
realized some of the major gripes I had with the Perl tap test output
were not actua
On 2024-06-13 Th 17:23, Robert Haas wrote:
On Thu, Jun 13, 2024 at 4:54 PM Andrew Dunstan wrote:
FTR, I have put a lot of effort into maintaining and improving the
infrastructure over the years. And I don't think there is anything much
more important. So I'm going to put more effort in. And I
On Thu, Jun 13, 2024 at 4:54 PM Andrew Dunstan wrote:
> FTR, I have put a lot of effort into maintaining and improving the
> infrastructure over the years. And I don't think there is anything much
> more important. So I'm going to put more effort in. And I'm not alone.
> Andres, Alvaro, Noah and T
On Thu, Jun 13, 2024 at 2:52 PM Jelte Fennema-Nio wrote:
> I understand and agree with your final stated goal of not ending up in
> another big mess. It's also clear to me that you don't think the
> current proposal achieves that goal. So I assume you have some
> additional ideas for the proposal
On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio wrote:
> I think 1 & 3 could be addressed by more easily giving commit/merge
> access to these tools than to the main PG repo. And I think 2 could be
> addressed by writing on the relevant wiki page where to go, and
> probably putting a link to the
On Thu, 13 Jun 2024 at 20:11, Robert Haas wrote:
> > But Perl is at the next level of unmaintained infrastructure. It is
> > actually clear how you can contribute to it, but still no new
> > community members actually want to contribute to it. Also, it's not
> > only unmaintained by us but it's al
On Thu, Jun 13, 2024 at 3:17 PM Greg Sabino Mullane wrote:
> I feel at least some of this is a visibility / marketing problem. I've not
> seen any dire requests for help come across on the lists, nor things on the
> various todos/road maps/ blog posts people make from time to time. If I had,
>
On 2024-06-12 We 18:43, Jelte Fennema-Nio wrote:
I agree it's not a technical issue. It is a people issue. There are
very few people skilled in Perl active in the community. And most of
those are very senior hackers that have much more important things to
do that make our Perl testing framewor
On Thu, Jun 13, 2024 at 11:11 AM Robert Haas wrote:
> I feel like I already agreed to this in a previous email and you're
> continuing to argue with me as if I were disagreeing.
I also think that maybe arguments are starting to sail past each
other, and the temperature is starting to climb. (And
On Thu, Jun 13, 2024 at 9:38 AM Robert Haas wrote:
> I agree with you, but I'm skeptical that solving it will be as easy as
> switching to Python. For whatever reason, it seems like every piece of
> infrastructure that the PostgreSQL community has suffers from severe
> neglect. Literally everythi
On 2024-06-13 Th 15:16, Greg Sabino Mullane wrote:
I'm very proficient with Perl.
Yes you are, and just as well!
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2024-06-12 We 11:50, Andres Freund wrote:
Hi,
On 2024-06-11 07:28:23 -0700, Jacob Champion wrote:
On Mon, Jun 10, 2024 at 1:04 PM Andres Freund wrote:
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is
On Thu, Jun 13, 2024 at 4:06 PM Jacob Champion
wrote:
> There was a four-step plan sketch at the end of that email, titled "A
> Plan". That was not intended to be "the final detailed plan", because
> I was soliciting feedback on the exact pieces people wanted to try to
> implement first, and I am
> On 13 Jun 2024, at 20:09, Melanie Plageman wrote:
>
> On Thu, Jun 13, 2024 at 7:27 AM Daniel Gustafsson wrote:
>>
>>> On 13 Jun 2024, at 00:34, Melanie Plageman
>>> wrote:
>>
>>> FWIW, I felt a lot of pain trying to write recovery TAP tests with
>>> IPC::Run's pumping functionality. It was
On 2024-06-12 We 18:34, Melanie Plageman wrote:
On Tue, Jun 11, 2024 at 8:05 AM Andrew Dunstan wrote:
On 2024-06-10 Mo 21:49, Andres Freund wrote:
Hi,
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
I'm not sure what part of the testing infrastructure you think is
unmaintained. For ex
On Thu, Jun 13, 2024 at 12:20 PM Robert Haas wrote:
> I interpreted Jacob's original email as articulating a goal ("For the
> v18 cycle, I would like to try to get pytest [1] in as a supported
> test driver, in addition to the current offerings") rather than a
> plan.
That's the first part of it.
On 2024-06-12 We 11:28, Andres Freund wrote:
Hi,
On 2024-06-11 08:04:57 -0400, Andrew Dunstan wrote:
Some time ago I did some work on wrapping libpq using the perl FFI module.
It worked pretty well, and would mean we could probably avoid many uses of
IPC::Run, and would probably be substantia
On Thu, Jun 13, 2024 at 3:28 PM Jacob Champion
wrote:
> (that's not the proposal and I know/think you know that but having my
> original email twisted into that is making me feel a bit crispy)
I definitely did not mean to imply that. I took your original email as
a goal, rather than a proposal or
On Thu, 13 Jun 2024 at 15:38, Robert Haas wrote:
> For whatever reason, it seems like every piece of
> infrastructure that the PostgreSQL community has suffers from severe
> neglect. Literally everything I know of either has one or maybe two
> very senior hackers maintaining it, or no maintainer a
On Thu, 13 Jun 2024 at 17:19, Tom Lane wrote:
> I wonder if we should be checking out some of the other newer
> languages that were mentioned upthread.
If this is actually something that we want to seriously evaluate, I
think that's a significant effort. And I think the people that want a
languag
On Thu, Jun 13, 2024 at 7:27 AM Daniel Gustafsson wrote:
>
> > On 13 Jun 2024, at 00:34, Melanie Plageman
> > wrote:
>
> > FWIW, I felt a lot of pain trying to write recovery TAP tests with
> > IPC::Run's pumping functionality. It was especially painful (as
> > someone who knows even less Perl t
On Thu, Jun 13, 2024 at 11:19 AM Tom Lane wrote:
> I wonder if we should be checking out some of the other newer
> languages that were mentioned upthread. It feels like going to
> Python here will lead to having two testing infrastructures with
> mas-o-menos the same capabilities, leaving us with
Jelte Fennema-Nio writes:
> You don't have to be fluent in writing Python to be able to read and
> understand tests written in it.
[ shrug... ] I think the same can be said of Perl, with about as
much basis. It matters a lot if you have previous experience with
the language.
Robert Haas writes:
> On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio wrote:
>> I agree it's not a technical issue. It is a people issue. There are
>> very few people skilled in Perl active in the community. And most of
>> those are very senior hackers that have much more important things to
>>
On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio wrote:
> I agree it's not a technical issue. It is a people issue. There are
> very few people skilled in Perl active in the community. And most of
> those are very senior hackers that have much more important things to
> do that make our Perl test
> On 13 Jun 2024, at 00:34, Melanie Plageman wrote:
> FWIW, I felt a lot of pain trying to write recovery TAP tests with
> IPC::Run's pumping functionality. It was especially painful (as
> someone who knows even less Perl than the "street fighting Perl"
> Thomas Munro has described having) before
On Wed, 12 Jun 2024 at 21:07, Robert Haas wrote:
> Yeah, I don't think depending on psycopg2 is practical at all. We can
> either shell out to psql like we do now, or we can use something like
> CFFI.
Quick clarification I meant psycopg3, not psycopg2. And I'd very much
like to avoid using psql f
On Tue, Jun 11, 2024 at 8:05 AM Andrew Dunstan wrote:
>
>
> On 2024-06-10 Mo 21:49, Andres Freund wrote:
>
> Hi,
>
> On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
>
> I'm not sure what part of the testing infrastructure you think is
> unmaintained. For example, the last release of Test::Simp
On Wed, 12 Jun 2024 at 18:46, Daniele Varrazzo
wrote:
> This is true, but [citation needed] :D I assume the pointer wanted to
> be https://www.psycopg.org/psycopg3/docs/api/pq.html#pq-impl
Ugh, yes I definitely meant to add a link to that [1]. I meant this one though:
[1]:
https://www.psycopg.o
Hi,
(I don't have an opinion which language should be selected
here.)
In
"Re: RFC: adding pytest as a supported test framework" on Wed, 12 Jun 2024
12:31:23 -0700,
Jacob Champion wrote:
> - I like Ruby as a language but have no experience using it for
> testing. (RSp
On Wed, Jun 12, 2024 at 01:40:30PM +0200, Jelte Fennema-Nio wrote:
> On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote:
> > I also want the initial scope to be the new language coexisting with the
> > existing Perl tests. If a bulk translation ever happens, it should happen
> > long after the debut
On Wed, Jun 12, 2024 at 10:30 AM Daniel Gustafsson wrote:
> I might be missing something obvious, but if we use a third-party libpq driver
> in the testsuite doesn't that imply that a patch adding net new functionality
> to libpq also need to add it to the driver in order to write the tests?
I us
On Wed, Jun 12, 2024 at 8:50 AM Andres Freund wrote:
> I think I might have formulated my paragraph above badly - I didn't mean that
> we should move away from perl tests tomorrow, but that we need a path forward
> that allows folks to write tests without perl.
Okay, agreed.
> > - Tests aren't c
On Wed, Jun 12, 2024 at 4:48 AM Alexander Korotkov wrote:
> Generally, testgres was initially designed as Python analogue of what
> we have in src/test/perl/PostgreSQL/Test. In particular its
> testgres.PostgresNode is analogue of PostgreSQL::Test::Cluster. It
> comes under PostgreSQL License.
On Wed, Jun 12, 2024 at 4:40 AM Jelte Fennema-Nio wrote:
> I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable
> choices for me (and possibly some more). They allow some type of
> introspection, they have a garbage collector, and their general
> tooling is quite good.
>
> But I think
On Tue, Jun 11, 2024 at 4:48 PM Noah Misch wrote:
> If we're going to test in a non-Perl language, I'd pick C over Python.
We already test in C, though? If the complaint is that those tests are
driven by Perl, I agree that something like libcheck or GTest or
whatever people are using nowadays wou
On Wed, Jun 12, 2024 at 1:30 PM Daniel Gustafsson wrote:
> > On 12 Jun 2024, at 17:50, Andres Freund wrote:
> > On 2024-06-11 07:28:23 -0700, Jacob Champion wrote:
>
> >> The OAuth pytest suite makes extensive use of
> >> - psycopg, to easily drive libpq;
> >
> > That's probably not going to fly.
On Wed, 12 Jun 2024 at 19:30, Daniel Gustafsson wrote:
> I might be missing something obvious, but if we use a third-party libpq driver
> in the testsuite doesn't that imply that a patch adding net new functionality
> to libpq also need to add it to the driver in order to write the tests? I'm
>
> On 12 Jun 2024, at 17:50, Andres Freund wrote:
> On 2024-06-11 07:28:23 -0700, Jacob Champion wrote:
>> The OAuth pytest suite makes extensive use of
>> - psycopg, to easily drive libpq;
>
> That's probably not going to fly. It introduces painful circular dependencies
> between building postgr
On Wed, Jun 12, 2024 at 7:34 PM Alexander Korotkov wrote:
> On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio wrote:
> > On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
> > > > The OAuth pytest suite makes extensive use of
> > > > - psycopg, to easily drive libpq;
> > >
> > > That's probably
On Wed, 12 Jun 2024 at 18:08, Jelte Fennema-Nio wrote:
>
> On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
> > > The OAuth pytest suite makes extensive use of
> > > - psycopg, to easily drive libpq;
> >
> > That's probably not going to fly. It introduces painful circular
> > dependencies
> >
> On 12 Jun 2024, at 18:08, Jelte Fennema-Nio wrote:
> On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
>> One thing worth thinking about is that such dependencies have to work on a
>> relatively large number of platforms / architectures. A lot of projects
>> don't...
>
> Do they really? A b
On Wed, Jun 12, 2024 at 7:08 PM Jelte Fennema-Nio wrote:
> On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
> > > The OAuth pytest suite makes extensive use of
> > > - psycopg, to easily drive libpq;
> >
> > That's probably not going to fly. It introduces painful circular
> > dependencies
> >
On Wed, 12 Jun 2024 at 17:50, Andres Freund wrote:
> > The OAuth pytest suite makes extensive use of
> > - psycopg, to easily drive libpq;
>
> That's probably not going to fly. It introduces painful circular dependencies
> between building postgres (for libpq), building psycopg (requiring libpq) a
Hi,
On 2024-06-11 07:28:23 -0700, Jacob Champion wrote:
> On Mon, Jun 10, 2024 at 1:04 PM Andres Freund wrote:
> > Just for context for the rest the email: I think we desperately need to move
> > off perl for tests. The infrastructure around our testing is basically
> > unmaintained and just abou
On Wed, 12 Jun 2024 at 15:49, FWS Neil wrote:
> I believe that anyone coming out of school these days would have a relatively
> easy transition to any of Go, Rust, Kotlin, Swift, etc. In other words, any
> of
> the modern languages.
Agreed, which is why I said they'd be acceptable to me. But I
Hi,
On 2024-06-11 08:04:57 -0400, Andrew Dunstan wrote:
> Some time ago I did some work on wrapping libpq using the perl FFI module.
> It worked pretty well, and would mean we could probably avoid many uses of
> IPC::Run, and would probably be substantially more efficient (no fork
> required). It
Jelte Fennema-Nio:
As scripting languages go, the ones that are still fairly heavily in
use are Javascript, Python, Ruby, and PHP. I think all of those could
probably work, but my personal order of preference would be Python,
Ruby, Javascript, PHP.
Finally, I'm definitely biased towards using Py
> On Jun 12, 2024, at 6:40 AM, Jelte Fennema-Nio wrote:
>
> I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable
> choices for me (and possibly some more). They allow some type of
> introspection, they have a garbage collector, and their general
> tooling is quite good.
>
Having
On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote:
> If we're going to test in a non-Perl language, I'd pick C over Python.
>
> We'd need a library like today's Perl
> PostgreSQL::Test to make C-language tests nice, but the same would apply to
> any new language.
P.P.S. We already write tests in C,
On Wed, Jun 12, 2024 at 2:48 PM Alexander Korotkov wrote:
> On Tue, Jun 11, 2024 at 5:31 PM Jacob Champion
> wrote:
> > On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov
> > wrote:
> > > Thank you for working on this.
> > > Do you think you could re-use something from testgres[1] package?
> >
On Tue, Jun 11, 2024 at 5:31 PM Jacob Champion
wrote:
> On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov
> wrote:
> > Thank you for working on this.
> > Do you think you could re-use something from testgres[1] package?
>
> Possibly? I think we're all coming at this with our own bags of tricks
On Wed, 12 Jun 2024 at 01:48, Noah Misch wrote:
> If we're going to test in a non-Perl language, I'd pick C over Python. There
> would be several other unlikely-community-choice languages I'd pick over
> Python (C#, Java, C++).
My main goals of this thread are:
1. Allowing people to quickly writ
On 2024-06-11 Tu 19:48, Noah Misch wrote:
On Mon, Jun 10, 2024 at 06:49:11PM -0700, Andres Freund wrote:
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
On 2024-06-10 Mo 16:04, Andres Freund wrote:
Just for context for the rest the email: I think we desperately need to move
off perl for
On Mon, Jun 10, 2024 at 06:49:11PM -0700, Andres Freund wrote:
> On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
> > On 2024-06-10 Mo 16:04, Andres Freund wrote:
> > > Just for context for the rest the email: I think we desperately need to
> > > move
> > > off perl for tests. The infrastructur
On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov
wrote:
> Thank you for working on this.
> Do you think you could re-use something from testgres[1] package?
Possibly? I think we're all coming at this with our own bags of tricks
and will need to carve off pieces to port, contribute, or reimplem
On Mon, Jun 10, 2024 at 1:04 PM Andres Freund wrote:
> Just for context for the rest the email: I think we desperately need to move
> off perl for tests. The infrastructure around our testing is basically
> unmaintained and just about nobody that started doing dev stuff in the last 10
> years lear
On 2024-06-10 Mo 21:49, Andres Freund wrote:
Hi,
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
On 2024-06-10 Mo 16:04, Andres Freund wrote:
Hi,
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is bas
Hi,
On 2024-06-10 16:46:56 -0400, Andrew Dunstan wrote:
>
> On 2024-06-10 Mo 16:04, Andres Freund wrote:
> > Hi,
> >
> >
> > Just for context for the rest the email: I think we desperately need to move
> > off perl for tests. The infrastructure around our testing is basically
> > unmaintained a
On Mon, 10 Jun 2024 at 22:47, Andrew Dunstan wrote:
> As for what up and coming developers learn, they mostly don't learn C either,
> and that's far more critical to what we do.
I think many up and coming devs have at least touched C somewhere
(e.g. in university). And because it's more critical
On Mon, 10 Jun 2024 at 20:46, Jacob Champion
wrote:
> For the v18 cycle, I would like to try to get pytest [1] in as a
> supported test driver, in addition to the current offerings.
Huge +1 from me (but I'm definitely biased here)
> Thoughts? Suggestions?
I think the most important thing is tha
On 2024-06-10 Mo 16:04, Andres Freund wrote:
Hi,
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is basically
unmaintained and just about nobody that started doing dev stuff in the last 10
years learned perl
Hi,
Just for context for the rest the email: I think we desperately need to move
off perl for tests. The infrastructure around our testing is basically
unmaintained and just about nobody that started doing dev stuff in the last 10
years learned perl.
On 2024-06-10 11:46:00 -0700, Jacob Champion
Hi!
On Mon, Jun 10, 2024 at 9:46 PM Jacob Champion
wrote:
> Thoughts? Suggestions?
Thank you for working on this.
Do you think you could re-use something from testgres[1] package?
Links.
1. https://github.com/postgrespro/testgres
--
Regards,
Alexander Korotkov
Supabase
Hi all,
For the v18 cycle, I would like to try to get pytest [1] in as a
supported test driver, in addition to the current offerings.
(I'm tempted to end the email there.)
We had an unconference session at PGConf.dev [2] around this topic.
There seemed to be a number of nodding heads and some gr
91 matches
Mail list logo
