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 |
Message-ID: | 1100325.1624025554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 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
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" |