Re: ISSTRICT behavior

From: Don Y <pgsql(at)DakotaCom(dot)Net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org, kleptog(at)svana(dot)org
Subject: Re: ISSTRICT behavior
Date: 2006-05-04 07:19:12
Message-ID: 4459AAF0.4020701@DakotaCom.Net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Don Y <pgsql(at)DakotaCom(dot)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...

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-05-04 07:23:05 Re: ISSTRICT behavior
Previous Message Martijn van Oosterhout 2006-05-04 07:06:27 Re: ISSTRICT behavior