Thread: Add missing copyright for pg_upgrade/t/* files
Dear hackers, 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. Best Regards, Hayato Kuroda FUJITSU LIMITED
Attachment
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][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. [1]: https://github.com/postgres/postgres/commit/f41e56c76e39f02bef7ba002c9de03d62b76de4d [2] https://github.com/postgres/postgres/commit/58ffe141eb37c3f027acd25c1fc6b36513bf9380 [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