Re: Internal key management system - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Internal key management system
Date
Msg-id alpine.DEB.2.22.394.2006122259560.473586@pseudo
Whole thread Raw
In response to Re: Internal key management system  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Hello Bruce.

>> The question is what should be put in the protocol, and I would tend to
>> think that some careful design time should be put in it.
>
> I still don't see the value of this vs. its complexity.

Dunno. I'm looking for the value of having such a thing in core.

ISTM that there are no clear design goals of the system, no clear 
description of the target use case(s), no clear explanations of the 
underlying choices (in something like a README), no saying what it 
achieves and what it does not achieve. It is only code.

If the proposed thing is very specific to one use case, which may be more 
or less particular, then I'd say the stuff should really be an external 
extension, and you do not need to ask for a review. Call it pgcryptoXYZ 
and it is done.

However, if the stuff is amenable to many/more use cases, then it may 
still be an extension because it is specialized somehow and not everyone 
would like to have it if they do not use it, but having it in core would 
be much more justified. Also, it would have to be a little more "complex" 
to be extensible, sure. I do not think that it needs to be very complex in 
the end, but it needs to be carefully designed to be extensible.

Note I still do not see why it should be in core directly, i.e. not an 
extension. I'm yet to see a convincing argument about that.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Andres Freund
Date:
Subject: Re: hashagg slowdown due to spill changes