On Thu, Jun 23, 2022 at 10:45:40PM -0700, Noah Misch wrote:
> On Wed, Jun 22, 2022 at 11:03:22AM -0400, Andrew Dunstan wrote:
> > On 2022-06-22 We 03:21, Noah Misch wrote:
> > > On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
> > >> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
>
On Wed, Jun 22, 2022 at 11:03:22AM -0400, Andrew Dunstan wrote:
> On 2022-06-22 We 03:21, Noah Misch wrote:
> > On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
> >> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
> >>> +*generate_ascii_string = *TestLib::generate_ascii_string;
> >>>
On 2022-06-22 We 03:21, Noah Misch wrote:
> On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
>> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
>>> +*generate_ascii_string = *TestLib::generate_ascii_string;
>>> +*slurp_dir = *TestLib::slurp_dir;
>>> +*slurp_file =
On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
> > +*generate_ascii_string = *TestLib::generate_ascii_string;
> > +*slurp_dir = *TestLib::slurp_dir;
> > +*slurp_file = *TestLib::slurp_file;
> >
> > I am not sure if it is possible
On 2022-04-21 09:42:44 -0400, Andrew Dunstan wrote:
> On 2022-04-21 Th 00:11, Michael Paquier wrote:
> > On Wed, Apr 20, 2022 at 03:56:17PM -0400, Andrew Dunstan wrote:
> >> Basically I propose just to remove any mention of the Testlib items and
> >> get_free_port from the export and alias lists
On 2022-04-21 Th 00:11, Michael Paquier wrote:
> On Wed, Apr 20, 2022 at 03:56:17PM -0400, Andrew Dunstan wrote:
>> Basically I propose just to remove any mention of the Testlib items and
>> get_free_port from the export and alias lists for versions where they
>> are absent. If backpatchers need
On Wed, Apr 20, 2022 at 03:56:17PM -0400, Andrew Dunstan wrote:
> Basically I propose just to remove any mention of the Testlib items and
> get_free_port from the export and alias lists for versions where they
> are absent. If backpatchers need a function they can backport it if
> necessary.
On 2022-04-19 Tu 20:30, Michael Paquier wrote:
> On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
>> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
>>> +*generate_ascii_string = *TestLib::generate_ascii_string;
>>> +*slurp_dir = *TestLib::slurp_dir;
>>> +*slurp_file =
On Tue, Apr 19, 2022 at 07:24:58PM -0400, Andrew Dunstan wrote:
> On 2022-04-19 Tu 18:39, Michael Paquier wrote:
>> +*generate_ascii_string = *TestLib::generate_ascii_string;
>> +*slurp_dir = *TestLib::slurp_dir;
>> +*slurp_file = *TestLib::slurp_file;
>>
>> I am not sure if it is possible and my
On 2022-04-19 Tu 18:39, Michael Paquier wrote:
> On Tue, Apr 19, 2022 at 04:06:28PM -0400, Andrew Dunstan wrote:
>> Here's a version with a fixed third patch that corrects a file misnaming
>> and fixes the export issue referred to above. Passes my testing so far.
> Wow. That's really cool. You
On Tue, Apr 19, 2022 at 04:06:28PM -0400, Andrew Dunstan wrote:
> Here's a version with a fixed third patch that corrects a file misnaming
> and fixes the export issue referred to above. Passes my testing so far.
Wow. That's really cool. You are combining the best of both worlds
here to ease
On 2022-04-19 Tu 11:36, Andrew Dunstan wrote:
> On 2022-04-18 Mo 14:07, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> No, I think we could probably just port the whole of src/test/PostreSQL
>>> back if required, and have it live alongside the old modules. Each TAP
>>> test is a separate miracle
Hi,
On 2022-04-19 11:36:44 -0400, Andrew Dunstan wrote:
> The attached three patches basically implement the new naming scheme for
> the back branches without doing away with the old scheme or doing a
> wholesale copy of the new modules.
That sounds like good plan!
I don't know perl enough to
On 2022-04-18 Mo 14:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> No, I think we could probably just port the whole of src/test/PostreSQL
>> back if required, and have it live alongside the old modules. Each TAP
>> test is a separate miracle - see comments elsewhere about port
>> assignment in
> On 18 Apr 2022, at 19:59, Andrew Dunstan wrote:
> On 2022-04-18 Mo 13:43, Tom Lane wrote:
>> Another thing that ought to be on the table is back-patching
>> 549ec201d (Replace Test::More plans with done_testing). Those
>> test counts are an even huger pain for back-patching than the
>>
On Mon, Apr 18, 2022 at 01:59:23PM -0400, Andrew Dunstan wrote:
> On 2022-04-18 Mo 13:43, Tom Lane wrote:
>> I doubt that just plopping the new Cluster.pm in alongside the old
>> file could work --- wouldn't the two modules need to share state
>> somehow?
>
> No, I think we could probably just
> On Apr 18, 2022, at 1:19 PM, Andrew Dunstan wrote:
>
> that seems quite separate from the present issue.
Thanks for the clarification. I agree, given your comments, that it is
unrelated to this thread.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On 2022-04-18 Mo 15:46, Mark Dilger wrote:
>
>> On Apr 18, 2022, at 10:59 AM, Andrew Dunstan wrote:
>>
>> No, I think we could probably just port the whole of src/test/PostreSQL
>> back if required, and have it live alongside the old modules. Each TAP
>> test is a separate miracle - see
> On Apr 18, 2022, at 10:59 AM, Andrew Dunstan wrote:
>
> No, I think we could probably just port the whole of src/test/PostreSQL
> back if required, and have it live alongside the old modules. Each TAP
> test is a separate miracle - see comments elsewhere about port
> assignment in parallel
On 2022-04-18 Mo 14:07, Tom Lane wrote:
> Andrew Dunstan writes:
>> No, I think we could probably just port the whole of src/test/PostreSQL
>> back if required, and have it live alongside the old modules. Each TAP
>> test is a separate miracle - see comments elsewhere about port
>> assignment
Andrew Dunstan writes:
> No, I think we could probably just port the whole of src/test/PostreSQL
> back if required, and have it live alongside the old modules. Each TAP
> test is a separate miracle - see comments elsewhere about port
> assignment in parallel TAP tests.
> But that would mean we
On 2022-04-18 Mo 13:43, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-04-18 Mo 11:52, Noah Misch wrote:
>>> On Mon, Apr 18, 2022 at 07:15:30AM -0700, Andres Freund wrote:
I just, again, tried to backport a test as part of a bugfix. The
renaming between 14 and 15 makes that task
Andrew Dunstan writes:
> On 2022-04-18 Mo 11:52, Noah Misch wrote:
>> On Mon, Apr 18, 2022 at 07:15:30AM -0700, Andres Freund wrote:
>>> I just, again, tried to backport a test as part of a bugfix. The
>>> renaming between 14 and 15 makes that task almost comically harder. The
>>> only way I see
On 2022-04-18 Mo 11:52, Noah Misch wrote:
> On Mon, Apr 18, 2022 at 07:15:30AM -0700, Andres Freund wrote:
>> I just, again, tried to backport a test as part of a bugfix. The
>> renaming between 14 and 15 makes that task almost comically harder. The
>> only way I see of dealing with that for the
On Mon, Apr 18, 2022 at 07:15:30AM -0700, Andres Freund wrote:
> I just, again, tried to backport a test as part of a bugfix. The
> renaming between 14 and 15 makes that task almost comically harder. The
> only way I see of dealing with that for the next 5 years is to just
> never backpatch tests
Hi,
On 2022-04-18 10:26:15 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I just, again, tried to backport a test as part of a bugfix. The
> > renaming between 14 and 15 makes that task almost comically harder. The
> > only way I see of dealing with that for the next 5 years is to just
> >
Andres Freund writes:
> I just, again, tried to backport a test as part of a bugfix. The
> renaming between 14 and 15 makes that task almost comically harder. The
> only way I see of dealing with that for the next 5 years is to just
> never backpatch tests to < 15. Which seems like a bad outcome.
Hi,
On 2021-10-25 17:12:08 +0900, Michael Paquier wrote:
> On Sun, Oct 24, 2021 at 10:46:30AM -0400, Andrew Dunstan wrote:
> > ... and pushed.
>
> Thanks!
I just, again, tried to backport a test as part of a bugfix. The
renaming between 14 and 15 makes that task almost comically harder. The
On Sun, Oct 24, 2021 at 10:46:30AM -0400, Andrew Dunstan wrote:
> ... and pushed.
Thanks!
--
Michael
signature.asc
Description: PGP signature
On 10/20/21 08:40, Andrew Dunstan wrote:
> On 10/19/21 11:22 PM, Michael Paquier wrote:
>> On Tue, Oct 19, 2021 at 10:16:06PM +0200, Erik Rijkers wrote:
[0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ]
[0002-move-PostgreSQL-Test-PostgresVersion-up-in-the-names.patch]
On 10/19/21 11:22 PM, Michael Paquier wrote:
> On Tue, Oct 19, 2021 at 10:16:06PM +0200, Erik Rijkers wrote:
>>> [0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ]
>>> [0002-move-PostgreSQL-Test-PostgresVersion-up-in-the-names.patch]
> It seems to me that the hardest part is
On Tue, Oct 19, 2021 at 10:16:06PM +0200, Erik Rijkers wrote:
>> [0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ]
>> [0002-move-PostgreSQL-Test-PostgresVersion-up-in-the-names.patch]
It seems to me that the hardest part is sorted out with the naming and
pathing of the modules, so
Op 19-10-2021 om 20:54 schreef Andrew Dunstan:
Discussion has gone quiet and the tree is now relatively quiet, so now
seems like a good time to do this. See attached patches.
> [0001-move-perl-test-modules-to-PostgreSQL-Test-namespace.patch ]
>
> On Sep 7, 2021, at 9:00 PM, Noah Misch wrote:
>
> I wondered about using PGXS:: as the namespace for all these modules
That immediately suggests perl modules wrapping C code, which is misleading for
these. See `man perlxstut`
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The
On Tue, Sep 07, 2021 at 07:43:47AM -0400, Andrew Dunstan wrote:
> On 9/6/21 1:08 AM, Michael Paquier wrote:
> > On Sat, Sep 04, 2021 at 09:58:08AM -0400, Andrew Dunstan wrote:
> >> On 9/4/21 2:19 AM, Noah Misch wrote:
> >>> plperl uses PostgreSQL:: as the first component of its Perl module
> >>>
On 9/6/21 1:08 AM, Michael Paquier wrote:
> On Sat, Sep 04, 2021 at 09:58:08AM -0400, Andrew Dunstan wrote:
>> On 9/4/21 2:19 AM, Noah Misch wrote:
>>> plperl uses PostgreSQL:: as the first component of its Perl module
>>> namespace.
>>> We shouldn't use both PostgreSQL:: and Postgres:: in the
On Mon, Sep 06, 2021 at 02:08:45PM +0900, Michael Paquier wrote:
> A minor point: this introduces PostgreSQL::Test::PostgresVersion.
> Could be this stripped down to PostgreSQL::Test::Version instead?
This fails to apply since 5fcb23c, but the conflicts are simple enough
to solve. Sorry about
On Sat, Sep 04, 2021 at 09:58:08AM -0400, Andrew Dunstan wrote:
> On 9/4/21 2:19 AM, Noah Misch wrote:
>> plperl uses PostgreSQL:: as the first component of its Perl module namespace.
>> We shouldn't use both PostgreSQL:: and Postgres:: in the same source tree, so
>> this change should not use
On Fri, Sep 03, 2021 at 03:34:24PM -0400, Andrew Dunstan wrote:
> On 8/25/21 10:08 AM, Robert Haas wrote:
> > On Wed, Aug 25, 2021 at 1:48 AM Michael Paquier wrote:
> >> On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:
> >>> On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan
> >>>
On Wed, Aug 25, 2021 at 1:48 AM Michael Paquier wrote:
> On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:
> > On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan wrote:
> >> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
> >> remainder don't care.
> >
> > I'd have gone
On Mon, Aug 23, 2021 at 03:39:15PM -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan wrote:
>> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
>> remainder don't care.
>
> I'd have gone with something starting with Postgres:: ... but I don't care
>
On Mon, Aug 23, 2021 at 3:03 PM Andrew Dunstan wrote:
> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
> remainder don't care.
I'd have gone with something starting with Postgres:: ... but I don't care much.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 8/11/21 9:30 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I'll recast my vote to make this line be
>> my $node = PgTest::Cluster->new('nodename');
>> which seems succint enough. I could get behind PgTest::PgCluster too,
>> but having a second Pg there seems unnecessary.
> Either of
Alvaro Herrera writes:
> I'll recast my vote to make this line be
> my $node = PgTest::Cluster->new('nodename');
> which seems succint enough. I could get behind PgTest::PgCluster too,
> but having a second Pg there seems unnecessary.
Either of those WFM.
regards,
On 2021-Aug-10, Andrew Dunstan wrote:
> If we were publishing them on CPAN that would be reasonable. But we're
> not, nor are we likely to, I believe. I'd rather not have to add two
> level of directory hierarchy for this, and this also seems a bit
> long-winded:
>
> my $node =
On 8/10/21 10:26 PM, Andrew Dunstan wrote:
> On 8/10/21 10:13 PM, Mark Dilger wrote:
>>> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>>>
>>> If we were publishing them on CPAN that would be reasonable. But we're
>>> not, nor are we likely to, I believe.
>> I'm now trying to understand
On 8/10/21 10:13 PM, Mark Dilger wrote:
>
>> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>>
>> If we were publishing them on CPAN that would be reasonable. But we're
>> not, nor are we likely to, I believe.
> I'm now trying to understand the purpose of the renaming. I thought the
>
On 8/10/21 9:25 PM, Michael Paquier wrote:
> On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:
>> I can live with that. I guess to be consistent we would also rename
>> PostgresVersion to PgVersion
> Are RewindTest.pm and SSLServer.pm things you are considering for a
> renaming as
> On Aug 10, 2021, at 7:11 PM, Andrew Dunstan wrote:
>
> If we were publishing them on CPAN that would be reasonable. But we're
> not, nor are we likely to, I believe.
I'm now trying to understand the purpose of the renaming. I thought the
problem was that RPM packagers wanted something
On 8/10/21 9:37 PM, Mark Dilger wrote:
>
>> On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
>>
>> use PgTest::Utils;
>> use PgTest::PostgresNode;
> Checking CPAN, it seems there are three older modules with names starting
> with "Postgres":
>
> Postgres
>
On Wed, Aug 11, 2021 at 9:37 AM Mark Dilger
wrote:
>
> > On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
> >
> > use PgTest::Utils;
> > use PgTest::PostgresNode;
>
> Checking CPAN, it seems there are three older modules with names starting
> with "Postgres":
>
> Postgres
>
> On Aug 10, 2021, at 7:10 AM, Andrew Dunstan wrote:
>
> use PgTest::Utils;
> use PgTest::PostgresNode;
Checking CPAN, it seems there are three older modules with names starting with
"Postgres":
Postgres
Postgres::Handler
Postgres::Handler::HTML
It would be
On Tue, Aug 10, 2021 at 11:02:13AM -0400, Andrew Dunstan wrote:
> I can live with that. I guess to be consistent we would also rename
> PostgresVersion to PgVersion
Are RewindTest.pm and SSLServer.pm things you are considering for a
renaming as well? It may be more consistent to put everything
On 8/10/21 10:40 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I will undertake to do the work, once we get the bike-shedding part done.
>> I'll kick that off by suggesting we move all of these to the namespace
>> PgTest, and rename TestLib to Utils, so instead of
>> use TestLib;
>>
On 2021-Aug-10, Andrew Dunstan wrote:
> I'll kick that off by suggesting we move all of these to the namespace
> PgTest, and rename TestLib to Utils, so [...] you would say
>
> use PgTest::Utils;
> use PgTest::PostgresNode;
WFM.
--
Álvaro Herrera Valdivia, Chile —
Andrew Dunstan writes:
> I will undertake to do the work, once we get the bike-shedding part done.
> I'll kick that off by suggesting we move all of these to the namespace
> PgTest, and rename TestLib to Utils, so instead of
> use TestLib;
> use PostgresNode;
> you would say
> use
On 5/20/21 5:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> While solving a problem with the Beta RPMs, I noticed that they export
>> our perl test modules as capabilities like this:
>> [andrew@f34 x86_64]$ rpm -q --provides -p
>> postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm |
Hi,
On Thu, 2021-05-20 at 15:47 -0400, Andrew Dunstan wrote:
> Meanwhile I would suggest that RPM maintainers exclude both requires
> and provides for these five names.
Done, thanks. Will appear in next beta build.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified
Andrew Dunstan writes:
> While solving a problem with the Beta RPMs, I noticed that they export
> our perl test modules as capabilities like this:
> [andrew@f34 x86_64]$ rpm -q --provides -p
> postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm | grep ^perl
> perl(PostgresNode)
>
While solving a problem with the Beta RPMs, I noticed that they export
our perl test modules as capabilities like this:
[andrew@f34 x86_64]$ rpm -q --provides -p
postgresql14-devel-14-beta1_PGDG.fc34.x86_64.rpm | grep ^perl
perl(PostgresNode)
perl(PostgresVersion)
60 matches
Mail list logo
