On 28/01/2008, Gregory Stark <[EMAIL PROTECTED]> wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> writes: > > > Do you thing some binary module that load some encrypted sources from > > files? It can be possible too. But if source code will be stored in > > pg_proc, then we need third method. Some like "obfuscate" (prev. are > > validate and call"), because we can't to store plain text to prosrc > > col. > > Is there a reason you couldn't, for instance, provide a function which takes > source code and encrypts it. Then you would write dump the data it spits into > your function declaration like: > > CREATE FUNCTION foo() returns integer AS $$ > ... base64 encoded data > $$ language "obfuscated:plperl"; >
it's solve problem with dump well, but it's similar to my solution. "obfuscated:plperl" can be virtual language - we can have one common handler, because there is same work. I am not sure. This doesn't care any better security, only add some other necessary external toolkit. With obfuscate column or obfuscate language (it carry same information) I can use prosrc and I have not problem with dump too. It is true, so obfuscate languages move dependency to out of core - but it is more complex. > "obfuscated:plperl"'s handler function would just decrypt it and pass it off > to plperl. you need same handler for plpgsql, python, sql, ... so why don't do it generally? Pavel > > There is a validator function which gets called when you create a function but > I don't think it has any opportunity to substitute its result for the original > in prosrc. That might be interesting for other applications like compiled > languages, though I think they would still want to save the source in prosrc > and the bytecode in probin. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL > training! > ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
