| 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: | Whole Thread | Raw Message | 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 |