automating perl compile time checking
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38821psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:20 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38821_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38821_1 && git checkout t38821_1Patchset v1 (message #1) is on t38821_1
Here is a follow up patch to last weeks commit allowing all perl files
to be checked clean for compile time errors and warnings.
The patch contains a simple script to run the checks. The code that
finds perl files is put in a function in a single file that is sourced
by the three locations that need it.
The directory pgperlcritic is renamed to perlcheck, as it not contains
the new script as well as pgperlcritic.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a single file that is sourced by the three locations that need it.
+1 on centralizing the find-files function.
The directory pgperlcritic is renamed to perlcheck, as it not contains the new script as well as pgperlcritic.
This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume:
--- /dev/null
+++ b/src/tools/perlcheck/pgperlcritic
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+# src/tools/pgperlcritic/pgperlcriticcheers ./daniel
On 06/05/2018 05:14 PM, Daniel Gustafsson wrote:
This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume:
Thanks. will fix.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018-Jun-05, Daniel Gustafsson wrote:
On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a single file that is sourced by the three locations that need it.
+1 on centralizing the find-files function.
+1 on that. Why do we need to make the new find_perl_files file
executable, given it's always sourced? (I would have given a .sh
extension because it's a lib not an executable, but I suppose that's
just matter of taste; we certainly don't have a policy about it).
Looks fine to me either way.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 06/11/2018 02:33 PM, Alvaro Herrera wrote:
On 2018-Jun-05, Daniel Gustafsson wrote:
On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a single file that is sourced by the three locations that need it.+1 on centralizing the find-files function.
+1 on that. Why do we need to make the new find_perl_files file
executable, given it's always sourced? (I would have given a .sh
extension because it's a lib not an executable, but I suppose that's
just matter of taste; we certainly don't have a policy about it).Looks fine to me either way.
I've committed this, but I'm fine if people want to tweak the names. It
probably doesn't need to be executable.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6/11/18 15:38, Andrew Dunstan wrote:
On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a single file that is sourced by the three locations that need it.+1 on centralizing the find-files function.
+1 on that. Why do we need to make the new find_perl_files file
executable, given it's always sourced? (I would have given a .sh
extension because it's a lib not an executable, but I suppose that's
just matter of taste; we certainly don't have a policy about it).Looks fine to me either way.
I've committed this, but I'm fine if people want to tweak the names. It
probably doesn't need to be executable.
Why is this being committed after feature freeze?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 06/11/2018 04:01 PM, Peter Eisentraut wrote:
On 6/11/18 15:38, Andrew Dunstan wrote:
On 5 Jun 2018, at 16:31, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that finds perl files is put in a function in a single file that is sourced by the three locations that need it.+1 on centralizing the find-files function.
+1 on that. Why do we need to make the new find_perl_files file
executable, given it's always sourced? (I would have given a .sh
extension because it's a lib not an executable, but I suppose that's
just matter of taste; we certainly don't have a policy about it).Looks fine to me either way.
I've committed this, but I'm fine if people want to tweak the names. It
probably doesn't need to be executable.Why is this being committed after feature freeze?
This affects pretty much nothing. In fact some of the other changes I've
recently committed were arguably more dangerous. Do you want me to
revert the whole lot?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
On 06/11/2018 04:01 PM, Peter Eisentraut wrote:
Why is this being committed after feature freeze?
This affects pretty much nothing. In fact some of the other changes I've
recently committed were arguably more dangerous. Do you want me to
revert the whole lot?
AFAICS this is adding testing, not "features", so it seems fine from here.
regards, tom lane
On 06/11/2018 03:38 PM, Andrew Dunstan wrote:
On 06/11/2018 02:33 PM, Alvaro Herrera wrote:
On 2018-Jun-05, Daniel Gustafsson wrote:
On 5 Jun 2018, at 16:31, Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
The patch contains a simple script to run the checks. The code that
finds perl files is put in a function in a single file that is
sourced by the three locations that need it.+1 on centralizing the find-files function.
+1 on that. Why do we need to make the new find_perl_files file
executable, given it's always sourced? (I would have given a .sh
extension because it's a lib not an executable, but I suppose that's
just matter of taste; we certainly don't have a policy about it).Looks fine to me either way.
I've committed this, but I'm fine if people want to tweak the names.
It probably doesn't need to be executable.
People might be interested to see the perlcritic and 'perl -cw" checks
in operation:
The module isn't actually using the scripts in src/tools/perlcheck,
because they are designed to be quiet and it's designed to be more
verbose, but apart from that it's doing exactly the same thing.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6/11/18 16:06, Andrew Dunstan wrote:
This affects pretty much nothing. In fact some of the other changes I've
recently committed were arguably more dangerous. Do you want me to
revert the whole lot?
No, but this whole let's clean up the Perl code initiative seemed to
have come out of nowhere after feature freeze. The Perl code was fine
before, so if we're going to be polishing it around it should go into
the next release. I would actually have liked to have had more time to
discuss some of the changes, since I didn't seem to agree to some of
them at first reading.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 06/15/2018 12:21 AM, Peter Eisentraut wrote:
On 6/11/18 16:06, Andrew Dunstan wrote:
This affects pretty much nothing. In fact some of the other changes I've
recently committed were arguably more dangerous. Do you want me to
revert the whole lot?No, but this whole let's clean up the Perl code initiative seemed to
have come out of nowhere after feature freeze. The Perl code was fine
before, so if we're going to be polishing it around it should go into
the next release. I would actually have liked to have had more time to
discuss some of the changes, since I didn't seem to agree to some of
them at first reading.
There were changes made for perlcritic, but almost none for this check.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services