Re: ISSTRICT behavior
От | Don Y |
---|---|
Тема | Re: ISSTRICT behavior |
Дата | |
Msg-id | 4459ABDB.7030008@DakotaCom.Net обсуждение исходный текст |
Ответ на | Re: ISSTRICT behavior (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: ISSTRICT behavior
|
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: