Re: PQinitSSL broken in some use casesf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Andrew Chernow <ac(at)esilo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PQinitSSL broken in some use casesf
Date: 2009-02-13 20:44:46
Message-ID: 18391.1234557886@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Fri, Feb 13, 2009 at 3:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> +1 for thinking ahead to the next time, but is a bit mask the right thing?

> What would you suggest? struct pointer? varargs?

Not sure. By definition, we're trying to predict an unforeseen
requirement, and that's always going to be tough.

I'm not too thrilled about a struct pointer, because that will introduce
the problem "which version of the struct is the client passing?".
A varargs arrangement could cover almost anything, but it also seems
like overkill.

I don't actually have an idea that sounds better than a bitmask,
I just wanted to see if anyone else did.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-02-13 20:51:38 Re: autovacuum not honoring pg_autovacuum in 8.3.5?
Previous Message Joshua D. Drake 2009-02-13 20:27:39 Re: The science of optimization in practical terms?