From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_waldump's inclusion of backend headers is a mess |
Date: | 2017-02-14 21:01:29 |
Message-ID: | 20170214210129.rq44dhhkzvu5u2ee@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> Thoughts, comments, objections, better ideas?
> >
> > No better ideas. I'm a bit concerned about declarations needed both by
> > normal and xlog related routines, but I guess that can be solved by a
> > third header as you did.
>
> Yeah, that doesn't seem bad to me. I think it's actually fairly
> unfortunate that we've just shoved declarations from 3 or 4 or 5
> different source files into a single header in many of these cases. I
> think it leads to not thinking clearly about what the dependencies
> between the different source files in the index AM stuff is, and
> certainly there seems to be some room for improvement there,
> especially with regard to gist and gin.
Agreed -- on a very quick read, I like the way you split the GIN
headers.
I don't think the concern is really the number of source files involved,
because I think in some places we're bad at splitting source files
sensibly.
> Sorting that out is a bigger
> project than I'm prepared to undertake right now, but I think this is
> probably a step in the right direction.
Yes, I think so too.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-02-14 21:03:24 | Re: Improve OR conditions on joined columns (common star schema problem) |
Previous Message | Pavel Stehule | 2017-02-14 20:49:05 | Re: possibility to specify template database for pg_regress |