Re: Add version macro to libpq-fe.h

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Boris Kolpackov <boris(at)codesynthesis(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, alvaro(dot)herrera(at)2ndquadrant(dot)com
Subject: Re: Add version macro to libpq-fe.h
Date: 2021-06-18 14:12:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Boris Kolpackov <boris(at)codesynthesis(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-18 14:24:20 Re: Centralizing protective copying of utility statements
Previous Message Fabien COELHO 2021-06-18 13:58:48 Re: pgbench bug candidate: negative "initial connection time"