Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Aug 15, 2011 at 16:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Don't think you should expose fsec_t, nor most of those macros. �The
>> foo_per_bar values are just namespace clutter.
> Hmm, ok. I just went for what seemed like a reasonable subset. I do
> also need the SECS_PER_DAY and those constants in order to be able to
> convert the timestamp value.
Uh ... "convert"? That seems to require a whole lot more knowledge
about timestamps than what is exposed by the proposed new header.
I thought you were just hoping to compile a struct containing a
TimestampTz field, not actually do anything with that field.
>> I don't like the idea of exposing those to frontends, either. �What do
>> you actually *need* out of that, and why?
> PrevLogSeg - which also brings in XLogSegsPerFile.
> XLogFileName
> XLogFileSize - which brings in XLogSegsPerFile and XLogSegSize
> PrevLogSeg should be self explaining, as should xlogfilename.
> XLogFileSize is required by XLByteAdvance() which is already in
> xlogdefs.h - so xlogdefs.h actually has a hidden dependency on
> xlog_internal.h here today.
Yeah, and the question remains why is "frontend" code using any of that?
I'm inclined to think that there is zero chance of this code being
"frontend" in the sense of being at any real arm's length from backend
implementation details, and so you should just forget these header
maneuvers and do what pg_resetxlog.c does, ie
/** We have to use postgres.h not postgres_fe.h here, because there's so much* backend-only stuff in the XLOG include
fileswe need. But we need a* frontend-ish environment otherwise. Hence this ugly hack.*/
#define FRONTEND 1
#include "postgres.h"
regards, tom lane
