From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: WIP: plpgsql source code obfuscation |
Date: | 2008-01-28 17:38:04 |
Message-ID: | 162867790801280938h34458b23wb5fc37bc09945350@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On 28/01/2008, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>
> >> In such a scheme I think you would put the key in an attribute of the
> >> language. Either in pg_lang or some configuration location which the
> >> obfuscate:plperl interpreter knows where to find.
> >>
> >
> > what is advantage?
>
> It wouldn't require any core changes. It would be just another PL language to
> load which can be installed like other ones. This could be a big advantage
> because it doesn't look like there is a lot of support for putting th
> obfuscation directly into the core code.
can be. but I am afraid so any changes are necessary in core too
Pavel
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's 24x7 Postgres support!
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-28 17:58:48 | Re: WIP: plpgsql source code obfuscation |
Previous Message | Simon Riggs | 2008-01-28 17:14:39 | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |