From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: warning when compiling utils/tqual.h |
Date: | 2014-03-17 17:03:49 |
Message-ID: | 20140317170349.GI16438@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-03-17 12:56:12 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-03-17 13:40:53 -0300, Alvaro Herrera wrote:
> >> There is of course a third choice which is to dictate that this function
> >> ought to be declared in reorderbuffer.h; but that would have the
> >> unpleasant side-effect that tqual.c would need to #include that.
>
> > I am pretty clearly against this.
>
> Let me get this straight. reorderbuffer.c exports a function that needs
> to be used by tqual.c. The obvious method to do this is to declare the
> function in reorderbuffer.h and have tqual.c #include that. Apparently
> you think it's better to have tqual.h declare the function. How is that
> not 100% backwards? Even worse that it requires more header-inclusion
> bloat for some functionality entirely unrelated to snapshots?
I don't think cmin/cmax are entirely unrelated to tuple visibility. If
it didn't require exposing reorderbuffer.c internals, it's
implementation should have been in tqual.c.
And a struct HTAB; wouldn't require including a header.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2014-03-17 17:03:52 | Re: First-draft release notes for next week's releases |
Previous Message | Andres Freund | 2014-03-17 17:00:12 | Re: warning when compiling utils/tqual.h |