> Personally, I still subscribe to the PNG design theory that
> conditionalizing code on overall version numbers isn't a very good idea.
> Version information should be tied as tightly as possible to the
> particular behavior for which it applies.
> http://www.w3.org/TR/PNG-Rationale.html#R.Chunk-naming-conventions
I don't disagree with you, but it's not always easy to separate things
that cleanly. pg_dump doesn't try to distinguish server capabilities,
just server versions (and I'm sure you'd scream bloody murder if
someone submitted a patch to refactor it... because that patch would
be hideous).
> It's even worse when the available version numbers aren't really
> "overall", which would be the case here. If we had such a function
> you can bet your bottom dollar that people would test it to distinguish
> behaviors that are really server-side, and then get burnt in the field
> when their app gets used with mismatched server and libpq versions.
I think that could be largely addressed through documentation. There
is no helpful for terminal stupidity anyway.
The reality is, right now we have a way to distinguish server
versions, but not client versions. That doesn't seem particularly
logical or consistent. Testing for client versions lets you do things
like check for breakage known to exist in versions < X, where there
may be no difference in the API, just the behavior. It also reduces
the need to make every non-backward-compatible change an API change.
Many people will only ever link against the most recent version and
will not care about backward-compatibility. It doesn't hurt to
provide a hook to those who do care.
> For the problem at hand, if we think it's important for an app to be
> able to tell whether libpq supports a particular initialization
> behavior, then adding a new function to provide that behavior seems
> like the best bet to me.
>
> So maybe that says that designing for extensibility in the function
> signature is misguided anyhow ...
It could certainly be overdone.
...Robert