Thread: 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
Attachment
On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas@gmail.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@pgadmin.org> wrote: > On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas@gmail.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@gmail.com> writes:
> On Mon, Jul 26, 2010 at 9:57 AM, Dave Page <dpage@pgadmin.org> wrote:
>> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas@gmail.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Jul 26, 2010 at 9:57 AM, Dave Page <dpage@pgadmin.org> wrote: >>> On Mon, Jul 26, 2010 at 2:49 PM, Robert Haas <robertmhaas@gmail.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