Re: PQinitSSL broken in some use casesf

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> BTW, the bitmask isn't perfect either --- doesn't it just reintroduce
>> the problem already complained of with your idea for PQinitSSL? That
>> is, how does the client know whether the function recognized all the
>> bits it passed?

> Well, if we add the PQgetLibraryVersion() function I suggested
> upthread, then it can check that first. I find it difficult to
> believe that isn't a good idea independently of how we solve this
> particular problem.

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

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.

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 ...

regards, tom lane