On Sep 25, 2008, at 1:14 PM, David Fetter wrote:
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.
Define "protection". If there is no effective way to query the
catalog and see function code at the SQL level, this is a complete and
effective form of protection - it's just not protection from somebody
with server-level access.
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.
I don't personally want this feature. But I can see where it's
valuable in some contexts, and if the understanding is correct, it can
be used responsibly. People misuse basic SQL all the time, but that
doesn't mean the basic SQL should be nonexistent or stupider.
You do have a very valid point in indicating the added maintenance
cost of any new feature, but protecting stuff at the SQL level is not
a complicated thing to do, and well, people concerned with this
feature can be the ones maintaining it - there seems to be a good many
already and existence of the feature would attract more. Could this
be implemented via a contrib/ module?
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.
I am not saying that C is an encryption technique. It does however
protect code from customer eyes. People are often not trying to truly
encrypt a protected algorithm, but removing maintainability, adding
cost to theft, and hiding code that's badly done.
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.
See my other posts talking about chipmakers. We should NOT add this
feature /for/ idiots, but the fact that idiots will inevitably end up
misusing any feature should not be a justification for not
implementing it.
Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
[EMAIL PROTECTED] (email/jabber/aim/msn)
http://www.bepress.com | +1 (510) 665-1200 x163
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
