Re: PQinitSSL broken in some use casesf
От | Robert Haas |
---|---|
Тема | Re: PQinitSSL broken in some use casesf |
Дата | |
Msg-id | 603c8f070902100834g500a606bu12914fa2b04c73a5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PQinitSSL broken in some use casesf (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Feb 10, 2009 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >>>> Well, you could create PQinitSSLExtended, but, as you say, the use >>>> case is pretty narrow... >>>> It would help if there were a PQgetLibraryVersion() function. >>> >>> Help how? There is nothing an app can do to work around the problem >>> AFAICS. Or if there were, we should just document it and not change >>> the code --- the use case for this is evidently too narrow to justify >>> complicating libpq's API even more. > >> It would let you assert that you were running against a version of >> libpq that has the functionality that you are attempting to use, thus >> eliminating the risk of silent failure. > > If that's all you want, then PQinitSSLExtended is a perfectly good > answer. Your app will fail to link if you try to use a library > version that hasn't got it. I agree. I was thinking that there might not be enough interest in this feature to add an API call just to support it, but I thought PQgetVersion() might be a more general solution. > I think documenting the workaround is a sufficient answer though. I don't have a strong opinion on that one way or the other, but Andrew seemed to be concerned that he was cut-and-pasting a fair amount of code. ...Robert
В списке pgsql-hackers по дате отправления: