Re: warning when compiling utils/tqual.h

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

In response to

Browse pgsql-hackers by date

  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