Re: PQinitSSL broken in some use casesf

On Mon, Mar 30, 2009 at 2:31 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > Tom Lane wrote:
>> >> And we get into the whole question of error handling, which is what
>> >> shot down that proposal last time.
>>
>> > Can you remind me of the details?  I don't remember that issue.
>> > Currently PQinitSSL() returns void, so I don't see an issue there.
>>
>> The point is exactly the same as the complaint about turning PQinitSSL's
>> argument into a bitmask: if you are trying to define an extensible API
>> then you need a way for the app to determine whether all the bits it
>> passed were recognizable by the library.
>
> It seems having the init function return the bits it recognized would be
> the logical return value.

I'm disinclined to go this route because, as Tom pointed out upthread,
there's no evidence at all that this problem is an instance of some
more general class. If it turns out that we need to initialize other
things, they're likely to be totally unrelated to SSL, and whether
they are or not, they may not be things that can be indicated using a
bitmask. For example, what happens if we someday add support for a
separate SSL library called FooSSL, and we happen to need a "char *"
to describe how it should be initialized?
Or we might need a whole "char *" or "int" argument for some purpose
unrelated to SSL. Then we'll have a PQinit() function that pretends
to be a general-purpose initialization mechanism but really isn't.

With enough wrangling, we might be able to convince ourselves that
we've designed something which is general enough to cover all
contingencies, but I'm not sure there's any good reason to put in that
much work. Adding a new API call is not really that big a deal,
especially given that we're retaining the old one for backward
compatibility. If we discover we need something else in the future,
we'll just add an API call for that, too.

...Robert