Martijn van Oosterhout wrote:
> On Wed, May 03, 2006 at 11:45:31PM -0700, Don Y wrote:
>> Martijn van Oosterhout wrote:
>>> Unfortunatly there is no way to ensure the user declares the function
>>> in SQL in the way your code expects. I remember a discussion once about
>>> allowing you to declare the essential function details in the C file so
>>> that Postgres could complain if the user got it wrong, but nothing ever
>>> came of it.
>>>
>>> In short, give them an INSTALL.sql and tell them to use it.
>> Is there any way to prevent them from *adding* these functions
>> (i.e. build them into template) so they have to use them the
>> way *I* have already defined them?
>
> I'm not sure if I'm understanding you correctly, but if you're asking
> "can I stop users from creating new SQL functions that use my existing
> C function in strange ways" then the answer is no. All you can do is
*That* was (one of) the questions. Or, "can I stop them from
using functions in ways that the parser CAN'T catch but which
could impact the reliability of the server, etc."
> stop postgresql from seeing the function under any circumstances, by
> declaring it "static" or using some other way to strip the symbol from
> the resulting library.
I don't want to hide the function; just ensure that no one
*redefines* the SQL interface to it in a manner that is
inconsistent with its implementation. If I can make the
implementation robust enough that it could protect itself
against this potential, that would be acceptable (hence
my original question). Barring that, I need to do whatever
it takes to safeguard the server so that it can't be brought
to its knees by a simple bug like failing to specify STRICT, etc.