Add missing copyright for pg_upgrade/t/* files

On Mon, Apr 3, 2023 at 7:25 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:

While reading codes, I noticed that pg_upgrade/t/001_basic.pl and
pg_upgrade/t/002_pg_upgrade.pl do not contain the copyright.

I checked briefly and almost all files have that, so I thought they missed it.
PSA the patch to fix them.

Yeah, it is good to have the Copyright to keep it consistent with
other test files and otherwise as well.

--- a/src/bin/pg_upgrade/t/001_basic.pl
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -1,3 +1,5 @@
+# Copyright (c) 2022-2023, PostgreSQL Global Development Group

How did you decide on the starting year as 2022?

--
With Regards,
Amit Kapila.

Dear Amit,

Thank you for responding!

Yeah, it is good to have the Copyright to keep it consistent with
other test files and otherwise as well.

--- a/src/bin/pg_upgrade/t/001_basic.pl
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -1,3 +1,5 @@
+# Copyright (c) 2022-2023, PostgreSQL Global Development Group

How did you decide on the starting year as 2022?

I checked the commit log.
About 001_basic.pl, it had been added at 2017 once but been reverted soon [1]https://github.com/postgres/postgres/commit/f41e56c76e39f02bef7ba002c9de03d62b76de4d[2]https://github.com/postgres/postgres/commit/58ffe141eb37c3f027acd25c1fc6b36513bf9380 [3: https://github.com/postgres/postgres/commit/322becb6085cb92d3708635eea61b45776bf27b6.
322bec added the file again at 2022[3], so I chose 2022.

About 002_pg_upgrade.pl, it has been added at the same time[3].
Definitively it should be 2022.

[1]: https://github.com/postgres/postgres/commit/f41e56c76e39f02bef7ba002c9de03d62b76de4d
[2]: https://github.com/postgres/postgres/commit/58ffe141eb37c3f027acd25c1fc6b36513bf9380 [3: https://github.com/postgres/postgres/commit/322becb6085cb92d3708635eea61b45776bf27b6
[3: https://github.com/postgres/postgres/commit/322becb6085cb92d3708635eea61b45776bf27b6

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

I checked the commit log.
About 001_basic.pl, it had been added at 2017 once but been reverted soon [1][2].
322bec added the file again at 2022[3], so I chose 2022.

About 002_pg_upgrade.pl, it has been added at the same time[3].
Definitively it should be 2022.

It is great to make sure each file has the Copyright and I see this
patch has already been committed.

Just curious, is there a rule to add Copyright to Postgres? For example,
if I run a command `grep -rn Copyright --include="*.pl" | awk -F ':'
{'print $2, $1'} | sort -nr` inside postgres/src/bin, It seems most
Copyright were added to the second line, but these two were added to the
very beginning (of course, there are three other files following this
pattern as well).

...

2 pg_archivecleanup/t/010_pg_archivecleanup.pl
2 pg_amcheck/t/005_opclass_damage.pl
2 pg_amcheck/t/004_verify_heapam.pl
2 pg_amcheck/t/003_check.pl
2 pg_amcheck/t/002_nonesuch.pl
2 pg_amcheck/t/001_basic.pl
2 initdb/t/001_initdb.pl
1 pg_verifybackup/t/010_client_untar.pl
1 pg_verifybackup/t/008_untar.pl
1 pg_upgrade/t/002_pg_upgrade.pl
1 pg_upgrade/t/001_basic.pl
1 pg_basebackup/t/011_in_place_tablespace.pl

David

Dear David,

It is great to make sure each file has the Copyright and I see this
patch has already been committed.

Thanks!
While checking more, I was surprised because I found many files which do not
have Copyright via " grep -Lr Copyright --exclude-dir .git ..." command.
I'm not sure whether it is expected, but all sql files in src/test/regress/sql and
many files in contrib do not have. Do you know something about it?

Just curious, is there a rule to add Copyright to Postgres?

Sorry, I'm not sure about it. Before submitting a patch I have checked the
manual that "PostgreSQL Coding Conventions", but I could not find any.

For example,
if I run a command `grep -rn Copyright --include="*.pl" | awk -F ':'
{'print $2, $1'} | sort -nr` inside postgres/src/bin, It seems most
Copyright were added to the second line, but these two were added to the
very beginning (of course, there are three other files following this
pattern as well).

There seems a tendency that Copyright for recently added files have added it to
the very beginning, but I can suspect from the result that there are no specific
rules about it.

```
$ grep -rn Copyright --include="*.pl" | awk -F ':' {'print $2'} | sort -nr | uniq -c
1 753
1 752
1 717
...
22 3
158 2
24 1
```

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

On 2023-04-24 Mo 03:08, Hayato Kuroda (Fujitsu) wrote:

Dear David,

It is great to make sure each file has the Copyright and I see this
patch has already been committed.

Thanks!
While checking more, I was surprised because I found many files which do not
have Copyright via " grep -Lr Copyright --exclude-dir .git ..." command.
I'm not sure whether it is expected, but all sql files in src/test/regress/sql and
many files in contrib do not have. Do you know something about it?

Just curious, is there a rule to add Copyright to Postgres?

Sorry, I'm not sure about it. Before submitting a patch I have checked the
manual that "PostgreSQL Coding Conventions", but I could not find any.

For example,
if I run a command `grep -rn Copyright --include="*.pl" | awk -F ':'
{'print $2, $1'} | sort -nr` inside postgres/src/bin, It seems most
Copyright were added to the second line, but these two were added to the
very beginning (of course, there are three other files following this
pattern as well).

There seems a tendency that Copyright for recently added files have added it to
the very beginning, but I can suspect from the result that there are no specific
rules about it.

```
$ grep -rn Copyright --include="*.pl" | awk -F ':' {'print $2'} | sort -nr | uniq -c
1 753
1 752
1 717
...
22 3
158 2
24 1
```

I suspect many of those came from the last time I did this, at commit
8fa6e6919c.

IIRC I added "\nCopyright...\n\n" at line 1 unless that was a "#!" line,
in which case I added it after line 1 (it was done via a sed script IIRC)

I think since then perltidy has dissolved some of the extra blank lines
added at the end.

I don't think we actually have a rule about it, but the pattern I
described doesn't seem unreasonable.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com