pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PQgetssl() and alternative SSL implementations
Date: Tue, 19 Aug 2014 15:09:57 -0400
Message-ID: <10419.1408475397@sss.pgh.pa.us> (raw)
In-Reply-To: <CABUevExpTZpMAMvr=BkeO5-XG_zgZP=TKdyCCpgEpYc0Htjr8Q@mail.gmail.com>
References: <53F1E989.8020609@vmware.com>
	<CA+TgmoZDJ6CKiuBMqNk3iS7LQ9GZuzS7RTYSOvRu8kJjRKWLng@mail.gmail.com>
	<CABUevExpTZpMAMvr=BkeO5-XG_zgZP=TKdyCCpgEpYc0Htjr8Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Aug 19, 2014 at 8:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I have a hard time believing that something like this will really
>> satisfy anyone.  Why not just add PQgetSchannelHandleOrWhatever() and
>> call it good?  We can try to be incredibly thorough in exposing the
>> information people want and we will still inevitably miss something
>> that someone cares about; worse, we'll spend an awful lot of time and
>> energy along the way.

> Well, for one you push the full burden onto the application.

Robert's got a point though: there is always going to be somebody who
wants something we fail to expose.  It's better to be able to say "well,
you can do PQgetssl and then munge it for yourself" than to have to say
"sorry, you're screwed".  So if we're going to define PQgetssl as
returning NULL when you're not using OpenSSL, I don't see why we
shouldn't expose a similarly-defined PQgetXXX for each other underlying
implementation we support.  There will not be that many of 'em, and
I suspect the people with very specific needs will not care about more
than one underlying library anyway.

This does not say that we shouldn't also try to have some
library-independent functionality for interrogating certificate state
etc.  Just that having an escape hatch isn't a bad thing.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (44+ messages)  latest in thread

Message-ID: <10419.1408475397@sss.pgh.pa.us>
Permalink:  ../10419.1408475397@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/10419.1408475397@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, magnus@hagander.net, robertmhaas@gmail.com, hlinnakangas@vmware.com
  Subject: Re: PQgetssl() and alternative SSL implementations
  In-Reply-To: <10419.1408475397@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox