Re: walprotocol.h vs frontends

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> I'm trying to make my streaming log receiver work properly with 9.1,
> and have come across a couple of things. The first one that's causing
> trouble is that the definition of the protocol is currently in
> walprotocol.h, which is not include:able in a frontend application.
> AFAICT, this is because it includes utils/timestamp.h, which doesn't
> work. AFAICT, this means that anybody other than our own backend who
> wants to talk our replication protocol has to copy the specific struct
> defines they want in their own code. This seems like a really bad
> idea. (In my case, it's the StandbyReplyMessage that I need, so I can
> make my client not get killed by the default settings for timeout)

> The basic reason for this is that we're putting TimestampTz fields in
> the protocol. This also means that the protocol actually changes
> definition depending on if the server is compiled with integer or
> float timestamps. While the replication itself breaks if these are
> different, this seems like a bad thing to expose in the protocol. It
> also makes life a lot harder on third party tools.

I don't really see why it matters, given that the data to be shipped is
also dependent on the timestamp format?

However, for a narrow fix, I could see moving the data type definition
to someplace with fewer dependencies. Perhaps split it into a separate
file timestamp_type.h, or something like that.

regards, tom lane