Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)

On Thu, Sep 25, 2008 at 01:05:26PM -0700, Casey Allen Shobe wrote:
> On Sep 15, 2008, at 7:19 PM, Tom Lane wrote:
>> The problem is that the people who ask for this type of feature are
>> usually imagining that they can put their code on
>> customer-controlled machines and it will be safe from the
>> customer's eyes.
>
> That's a broken expectation.  All that can realistically be expected
> is database/catalog-level constraints.

It's far from clear that those offer protection of any reasonable kind.

>> Well, it isn't, and I don't think Postgres should encourage them to
>> think it is.
>
> Adding such a feature would NOT be encouraging them to think this - the
> documentation could be very explicit about this fact.  Maybe that's what
> Oracle is selling, and that's crappy of them, but that doesn't mean we
> should use that as justification to not add a more appropriate
> implementation.

You've got the burden of proof exactly backwards there.  It's on you
or anyone who cares to to explain why it might be a good idea to add
this "feature," understanding that every feature has a maintenance
cost and is a potential source of bugs.

> As for the expectation above - could pl/pgsql be made compilable?
> It  would seem easy to translate pl/pgsql code into C and compile a
> C  function.  That *could* go onto customer-controlled machines and
> be safe from the customer's eyes.

No, it would not.  As many others have mentioned, "strings" does a
pretty good job on such stuff, let alone the impossibility even in
theory of hiding what a program does from someone with access to run
it using arbitrary inputs, even when they have no binary to examine.

> FWIW, I think most people who want to hide code aren't concerned about
> IP, they're concerned about clients seeing embarrassingly bad/sloppy
> code.  But there *are* some very real and legitimate needs for this,
> though it's a small minority of those who think they do.

Please elucidate those needs in detail, then explain why it might be
PostgreSQL's job to meet them.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate