Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers