Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Jun 17, 2021 at 2:34 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> ... Just because the
>> version-number approach offloads work from us doesn't make it a good
>> idea, because the work doesn't vanish; it will be dumped in the laps
>> of packagers and end users.
> What work? Including an additional #define in a header file doesn't
> create any work for packagers or end-users that I can see. If
> anything, it seems easier for end-users. If you want a function that
> first appears in v16, just test whether the version number is >= 16.
You're omitting the step of "figure out which version the feature you
want to use appeared in". A few years down the road, that'll get
harder than it might seem to be for a shiny new feature.
As for the packagers, this creates a requirement to include the right
version of the right file in the right sub-package. Admittedly, if
we hack things so that the #define appears directly in libpq-fe.h through
some configure magic, then there's nothing extra for packagers to get
right; but if we put it anywhere else, we're adding ways for them to
get it wrong.
> On the other hand if we promise to add at least one #define to that
> file for each new release,
New libpq API feature, not every new release. I don't really see
that that's much harder than, say, bumping catversion.
> ... then somebody's got to be like, oh, let's
> see, this function was added in v16, now which #define got added in
> that release ... hmm, let me go diff the branches in git ... how is
> that any better?
I repeat that you are evaluating this through the lens of how much
work it is for us as opposed to other people, and I fundamentally
disagree with that being the primary metric.
regards, tom lane
