Re: SSL cipher and version

Last week, I ran across a situation where I needed to know the SSL
version and cipher in use for a particular database connection.
Magnus pointed me to contrib/sslinfo, but that didn't have quite what
I needed. The attached patch adds two additional functions to
contrib/sslinfo to report this information.

Any objections to me committing this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Last week, I ran across a situation where I needed to know the SSL
> version and cipher in use for a particular database connection.
> Magnus pointed me to contrib/sslinfo, but that didn't have quite what
> I needed.  The attached patch adds two additional functions to
> contrib/sslinfo to report this information.
>
> Any objections to me committing this?

Might wanna fix this first:

+PG_FUNCTION_INFO_V1(ssl_veresion);
^^^^^^^^^^^^

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Mon, Jul 26, 2010 at 9:57 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Last week, I ran across a situation where I needed to know the SSL
>> version and cipher in use for a particular database connection.
>> Magnus pointed me to contrib/sslinfo, but that didn't have quite what
>> I needed.  The attached patch adds two additional functions to
>> contrib/sslinfo to report this information.
>>
>> Any objections to me committing this?
>
> Might wanna fix this first:
>
> +PG_FUNCTION_INFO_V1(ssl_veresion);
>                                         ^^^^^^^^^^^^

Wow. It works remarkably well without fixing that, but I'll admit
that does seem lucky.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 26, 2010 at 9:57 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Any objections to me committing this?
>>
>> Might wanna fix this first:
>>
>> +PG_FUNCTION_INFO_V1(ssl_veresion);
>> ^^^^^^^^^^^^

> Wow. It works remarkably well without fixing that, but I'll admit
> that does seem lucky.

Well, it's got no arguments, which is the main thing that works
differently in call protocol V1. I think you'd find that the
PG_RETURN_NULL case doesn't really work though ...

regards, tom lane

On Tue, Jul 27, 2010 at 12:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jul 26, 2010 at 9:57 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> Any objections to me committing this?
>>>
>>> Might wanna fix this first:
>>>
>>> +PG_FUNCTION_INFO_V1(ssl_veresion);
>>>                                         ^^^^^^^^^^^^
>
>> Wow.  It works remarkably well without fixing that, but I'll admit
>> that does seem lucky.
>
> Well, it's got no arguments, which is the main thing that works
> differently in call protocol V1.  I think you'd find that the
> PG_RETURN_NULL case doesn't really work though ...

It seems to work, but it might be that something's broken under the hood.

Anyhow, committed with that correction.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company