Is this a TODO? --------------------------------------------------------------------------- Tom Lane wrote: > "Merlin Moncure" <mmoncure@xxxxxxxxx> 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
