Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id BACBA2E381F for ; Thu, 20 Dec 2007 19:02:25 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 41114-02 for ; Thu, 20 Dec 2007 19:02:10 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 7E4F72E41B0 for ; Thu, 20 Dec 2007 19:02:10 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lBKN1wD6020378; Thu, 20 Dec 2007 18:01:58 -0500 (EST) To: "Merlin Moncure" cc: "Alvaro Herrera" , "Joshua D. Drake" , "Trevor Talbot" , "Roberts, Jon" , "Kris Jurka" , "Jonah H. Harris" , "Bill Moran" , pgsql-performance@postgresql.org Subject: Re: viewing source code In-reply-to: References: <1A6E6D554222284AB25ABE3229A92762112A33@nrtexcus702.int.asurion.com> <476A9ADF.5030101@commandprompt.com> <90bce5730712201047m4dd0fe05k6b1fccc57897326f@mail.gmail.com> <20071220114011.64a650d7@commandprompt.com> <20071220200739.GC11586@alvh.no-ip.org> Comments: In-reply-to "Merlin Moncure" message dated "Thu, 20 Dec 2007 15:35:42 -0500" Date: Thu, 20 Dec 2007 18:01:58 -0500 Message-ID: <20377.1198191718@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/335 X-Sequence-Number: 28151 "Merlin Moncure" writes: > I don't really agree that wrapping pl/pgsql with encryptor/decryptor > is a bad idea. It's quite a good idea, because it has more than zero chance of succeeding politically in the community. The fundamental reason why preventing access to pg_proc.prosrc won't happen is this: all the pain (and there will be plenty) will be inflicted on people who get none of the benefit (because they don't give a damn about hiding their own functions' code). The folks who want function hiding can shout all they want, but as long as there is a very sizable fraction of the community who flat out *don't* want it, it's not going to get applied. Encrypted function bodies avoid this problem because they inflict no performance penalty, operational complexity, or client-code breakage on people who don't use the feature. They are arguably also a better solution because they can guard against more sorts of threats than a column-hiding solution can. I don't deny that the key-management problem is interesting, but it seems soluble; moreover, the difficulties that people have pointed to are nothing but an attempt to move the goalposts, because they correspond to requirements that a column-hiding solution would never meet at all. So if you want something other than endless arguments to happen, come up with a nice key-management design for encrypted function bodies. regards, tom lane