My suggestion is to extend PL API and each PL language should offer wrap or encrypt function which generate encrypted code and this code will be store in the pg_proc. PL language will be responsible to detect if it raw or crypted code. PG_Dump will dump crypted procedure and author is responsible keep his uncrypted version in source repository.
That strategy assumes that there is no way to reproduce the source form from the encrypted form. That means that the PL compiler must be able to recognize two different languages (the unencrypted form and the encrypted form). That may work for PL/pgSQL but it won't work for any language where a third-party compiler is involved (unless the decryption function produces an obfuscated source form that represents legitimate code for the compiler in question).


The basic problem is this: if you have to decrypt the code in order to give it to a compiler (PL/pgSQL, Java, Perl, ...) then there is a point in time where the source code is in plaintext form - it would be trivial to add an fprintf( stderr, "%s", plainTextForm ) to the PL handler to steal the code.

      -- Korry

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to