From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Postgres perl module namespace |
Date: | 2021-08-11 02:33:50 |
Message-ID: | b0331ef7-ae71-6a8a-2e5f-5d46c97a6e35@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <andrew(at)dunslane(dot)net> 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 that was unlikely to collide. Publishing on CPAN would be the way to claim the namespace.
>>
>> What's the purpose of this idea then? If there isn't one, I'd rather just keep the current names.
>
>
> Yes we want them to be in a namespace where they are unlikely to collide
> with anything else. No, you don't have to publish on CPAN to achieve that.
>
Incidentally, not publishing on CPAN was a major reason given a few
years ago for using fairly lax perlcritic policies. If we publish these
on CPAN now some people at least might want to revisit that decision.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Wu Haotian | 2021-08-11 03:15:00 | Re: Add option --drop-cascade for pg_dump/restore |
Previous Message | Andrew Dunstan | 2021-08-11 02:26:42 | Re: Postgres perl module namespace |