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
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
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 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 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 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 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 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
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 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
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 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 Sun, Oct 24, 2021 at 10:46:30AM -0400, Andrew Dunstan wrote:
> ... and pushed.
Thanks!
--
Michael
signature.asc
Description: PGP signature
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
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 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:
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 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 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 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 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 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: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 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 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 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
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 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
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 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 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 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-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 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 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:
> >
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
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 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
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
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
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 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:
> 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 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 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 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 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 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 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 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
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-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 -
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 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 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 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 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-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 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
59 matches
Mail list logo