Re: Synchronize with imath upstream - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Synchronize with imath upstream
Date
Msg-id 20190208043844.GA562856@rfd.leadboat.com
Whole thread Raw
In response to Re: Synchronize with imath upstream  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Synchronize with imath upstream  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Feb 07, 2019 at 10:12:05AM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Wed, Feb 06, 2019 at 10:15:24AM -0500, Tom Lane wrote:
> >> I don't object to keeping imported code in a form that matches upstream
> >> as best we can.  (Should we also exclude such files from pgindent'ing?)
> 
> > I think it depends on how much time one spends merging upstream changes versus
> > making PostgreSQL-specific edits.  For IMath, both amounts are too small to
> > get excited about.  Does pgindent materially complicate src/timezone merges?
> 
> My practice with src/timezone is to pgindent the upstream code and then
> diff it; given that extra step, it's not really any more complex (and
> maybe less so, as this hides minor whitespace changes for instance).

Let's continue to pgindent src/timezone and IMath, then.

> There are some other deltas to worry about as well, see
> src/timezone/README.
> 
> I have no particular opinion on whether pgindent should be part of the
> mix for imath, but I do strongly recommend setting up and documenting a
> reproducible import process, as I did for src/timezone.

Good idea.  I've modified the imath.c header comment to take the form of an
import process; see attached imath1.29-pgedits-v2.patch.

Attachment

pgsql-hackers by date:

Previous
From: rajan
Date:
Subject: Re: Able to do ALTER DEFAULT PRIVILEGES from a user who is not theowner
Next
From: "Imai, Yoshikazu"
Date:
Subject: RE: speeding up planning with partitions