Boris Kolpackov <boris@codesynthesis.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I think putting a version number as such in there is a truly
>> horrid idea. However, I could get behind adding a boolean flag
>> that says specifically whether the pipeline feature exists.
> That would be even better, but I agree with what others have
> said: we would have to keep adding such feature test macros
> going forward.
Yes, and I think that is a superior solution. I think the
argument that it's too much effort is basically nonsense.
> I think ideally you would want to have both since the version
> macro could still be helpful in dealing with "features" that you
> did not plan to add (aka bugs).
I really doubt that a version number appearing in libpq-fe.h would
be helpful for deciding whether you need to work around a bug.
The problem again is version skew: how well does the libpq.so you
are running against today match up with the header you compiled
against (possibly months ago, possibly on a different machine)?
What you'd want for that sort of thing is a runtime test, i.e.
consult PQlibVersion().
That point, along with the previously-discussed point about confusion
between server and libpq versions, nicely illustrates another reason
why I'm resistant to just adding a version number to libpq-fe.h.
If we do that, application programmers will be presented with THREE
different Postgres version numbers, and it seems inevitable that
people will make mistakes and consult the wrong one for a particular
purpose. I think we can at least reduce the confusion by handling
the question of which-features-are-visible-in-the-include-file in a
different style.
regards, tom lane