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 = *TestLib::slurp_fi
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
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 fo
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.
Agree
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 = *TestLib::slu
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 p
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 bac
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 co
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
>> renaming
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 por
> 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 Comp
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 comments
> 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 T
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
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 ha
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 a
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 o
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 t
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
> > ne
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
only
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 sorted
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 ]
> [0002-move-PostgreSQL-Test-PostgresVersion-up-
> 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 En
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
> >>> n
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 s
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 tha
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 Post
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
> >>> 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 wrote:
> >> OK, I count 3 in favor of changing to PgTest::Cluster, 1 against,
> >> remainder don't care.
> >
> > I'd have gone w
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
> much
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 t
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, t
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 = PostgreSQL::Te
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 the
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
> prob
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 w
> 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 tha
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
> Postgres::Handle
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 in
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;
>> us
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 — https:
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 PgT
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 | gr
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 Engi
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)
> per
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)
perl(Recurs
60 matches
Mail list logo
