Thread

Commits

  1. Fix incorrect year in some copyright notices added this year

  1. Fixup a few 2023 copyright years

    David Rowley <dgrowleyml@gmail.com> — 2024-04-09T02:21:42Z

    Attached is a patch which adjusts the copyright years of 2023 that
    have crept in this year from patches that were written last year and
    committed without adjusting this to 2024.
    
    The patch isn't produced by src/tools/copyright.pl as that'll
    transform files which are new and only contain "2023" to become
    "2023-2024", which I don't believe is what we want in this case.
    
    No other matches aside from .po files from:
    git grep -e "Copyright" --and --not -e "2024" --and -e "PostgreSQL
    Global Development Group"
    
    Should we do this and is this a good time to?
    
    David
    
  2. Re: Fixup a few 2023 copyright years

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-04-09T02:36:41Z

    David Rowley <dgrowleyml@gmail.com> writes:
    > Attached is a patch which adjusts the copyright years of 2023 that
    > have crept in this year from patches that were written last year and
    > committed without adjusting this to 2024.
    
    > The patch isn't produced by src/tools/copyright.pl as that'll
    > transform files which are new and only contain "2023" to become
    > "2023-2024", which I don't believe is what we want in this case.
    
    Agreed, copyright.pl is not quite the right tool, although you could
    use its output as a starting point and manually adjust any wrong
    changes.
    
    > Should we do this and is this a good time to?
    
    We *should* do this sometime before branching v17, but I'm not
    in any hurry.  My thought here is that some of these late changes
    might end up getting reverted, in which case touching those files
    would add a bit more complexity to the revert.  We can do this
    sort of mechanical cleanup after the probability of reversion has
    declined a bit.
    
    (On the same logic, I'm resisting the temptation to do a tree-wide
    pgindent right away.  Yeah, the tree is indent-clean according to
    the current contents of src/tools/pgindent/typedefs.list, but that
    hasn't been maintained with great accuracy, so we'll need an
    update and then a pgindent run at some point.)
    
    			regards, tom lane
    
    
    
    
  3. Re: Fixup a few 2023 copyright years

    Michael Paquier <michael@paquier.xyz> — 2024-04-09T03:25:43Z

    On Mon, Apr 08, 2024 at 10:36:41PM -0400, Tom Lane wrote:
    > We *should* do this sometime before branching v17, but I'm not
    > in any hurry.  My thought here is that some of these late changes
    > might end up getting reverted, in which case touching those files
    > would add a bit more complexity to the revert.  We can do this
    > sort of mechanical cleanup after the probability of reversion has
    > declined a bit.
    > 
    > (On the same logic, I'm resisting the temptation to do a tree-wide
    > pgindent right away.  Yeah, the tree is indent-clean according to
    > the current contents of src/tools/pgindent/typedefs.list, but that
    > hasn't been maintained with great accuracy, so we'll need an
    > update and then a pgindent run at some point.)
    
    The perl code in the tree has gathered dust, on the contrary ;)
    
    I would suggest to also wait until we're clearer with the situation
    for all these mechanical changes, which I suspect is going to take 1~2
    weeks at least.
    --
    Michael
    
  4. Re: Fixup a few 2023 copyright years

    David Rowley <dgrowleyml@gmail.com> — 2024-05-15T03:03:00Z

    On Tue, 9 Apr 2024 at 15:26, Michael Paquier <michael@paquier.xyz> wrote:
    > I would suggest to also wait until we're clearer with the situation
    > for all these mechanical changes, which I suspect is going to take 1~2
    > weeks at least.
    
    Since the Oid resequencing and pgindent run is now done, I've pushed this patch.
    
    David
    
    
    
    
  5. Re: Fixup a few 2023 copyright years

    Michael Paquier <michael@paquier.xyz> — 2024-05-15T05:32:22Z

    On Wed, May 15, 2024 at 03:03:00PM +1200, David Rowley wrote:
    > On Tue, 9 Apr 2024 at 15:26, Michael Paquier <michael@paquier.xyz> wrote:
    >> I would suggest to also wait until we're clearer with the situation
    >> for all these mechanical changes, which I suspect is going to take 1~2
    >> weeks at least.
    > 
    > Since the Oid resequencing and pgindent run is now done, I've pushed this patch.
    
    Thanks, that looks correct.
    
    While running src/tools/copyright.pl, I have noticed that that a
    newline was missing at the end of index_including.sql, as an effect of
    the test added by you in a63224be49b8.  I've cleaned up that while on
    it, as it was getting added automatically, and we tend to clean these
    like in 3f1197191685 or more recently c2df2ed90a82.
    --
    Michael
    
  6. Re: Fixup a few 2023 copyright years

    David Rowley <dgrowleyml@gmail.com> — 2024-05-15T11:25:39Z

    On Wed, 15 May 2024 at 17:32, Michael Paquier <michael@paquier.xyz> wrote:
    > While running src/tools/copyright.pl, I have noticed that that a
    > newline was missing at the end of index_including.sql, as an effect of
    > the test added by you in a63224be49b8.  I've cleaned up that while on
    > it, as it was getting added automatically, and we tend to clean these
    > like in 3f1197191685 or more recently c2df2ed90a82.
    
    Thanks for fixing that.  I'm a little surprised that pgindent does not
    fix that sort of thing.
    
    David
    
    
    
    
  7. Re: Fixup a few 2023 copyright years

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-05-15T14:30:56Z

    David Rowley <dgrowleyml@gmail.com> writes:
    > On Wed, 15 May 2024 at 17:32, Michael Paquier <michael@paquier.xyz> wrote:
    >> While running src/tools/copyright.pl, I have noticed that that a
    >> newline was missing at the end of index_including.sql, as an effect of
    >> the test added by you in a63224be49b8.  I've cleaned up that while on
    >> it, as it was getting added automatically, and we tend to clean these
    >> like in 3f1197191685 or more recently c2df2ed90a82.
    
    > Thanks for fixing that.  I'm a little surprised that pgindent does not
    > fix that sort of thing.
    
    pgindent does not touch anything but .c and .h files.
    
    I do recommend running "git diff --check" (with --staged if you
    already git-added your changes) before you're ready to commit
    something.  That does find generic whitespace issues, and I
    believe it would've found this one.
    
    			regards, tom lane