Re: ISSTRICT behavior
От | Don Y |
---|---|
Тема | Re: ISSTRICT behavior |
Дата | |
Msg-id | 4459AAF0.4020701@DakotaCom.Net обсуждение исходный текст |
Ответ на | Re: ISSTRICT behavior (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ISSTRICT behavior
|
Список | pgsql-general |
Tom Lane wrote: > Don Y <pgsql@DakotaCom.Net> writes: >> 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? > > Only if you think you can deny your users superuser privileges on > their own databases. Good luck selling that one (I sure wouldn't > buy any code that tried to enforce such a thing) I'm not designing for the "traditional" role that you're used to so I can do whatever makes sense for this product and just *define* that as it's behavior. Since there are no other products that compete with it, users don't really have much choice! :> Having said that, I don't want to be arbitrary in the impositions I make on others. One potential workaround is to just disable the ability to add functions altogether. Those that I opt to build in can be proven to work properly and other functions can just be prohibited. Thus, no need to worry about the user failing to declare the functions properly. Another option (for *me*) is to hack the parser so that it applies the STRICT modifier to all CREATE FUNCTION declarations implicitly. And, change the rules for function definitions so that the function will know that it will never be invoked with NULL. But, that's also heavy-handed. I'd prefer to just build functions that are robust enough to handle this "loophole" in the declaration/definition interfaces and let other folks copy that model if they chose to write their own functions. The more I bastardize the user interface, the less usable my codebase will be for use by "mainstream" developers. :-( I already have several changes that won't back port due to their application specific nature; I'm trying to keep the number of such changes to a minimum...
В списке pgsql-general по дате отправления: