Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:23:07AM -0700, Don Y wrote:
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 co
Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:29:30AM -0700, Don Y wrote:
OTOH, if the function could *abort* it's invocation, then
I don't have to worry about return values. It is a closer
model to the STRICT behavior -- instead of aborting the
function invocation BEFORE (which STRI
Martijn van Oosterhout wrote:
On Thu, May 04, 2006 at 12:19:12AM -0700, Don Y wrote:
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
On Thu, May 04, 2006 at 12:29:30AM -0700, Don Y wrote:
> OTOH, if the function could *abort* it's invocation, then
> I don't have to worry about return values. It is a closer
> model to the STRICT behavior -- instead of aborting the
> function invocation BEFORE (which STRICT essentially does),
> I
On Thu, May 04, 2006 at 12:23:07AM -0700, Don Y wrote:
> 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
> agai
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
First, if the function is defined to return an INT16,
then returning a NULL doesn't make any sense -- since the
caller doesn't know how to deal with a NULL (it expects
an INT16, for example).
Really? That would be a caller bug, if it's calling
On Thu, May 04, 2006 at 12:19:12AM -0700, Don Y wrote:
> 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 ha
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
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> 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
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
Don Y <[EMAIL PROTECTED]> 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 s
Don Y <[EMAIL PROTECTED]> writes:
> First, if the function is defined to return an INT16,
> then returning a NULL doesn't make any sense -- since the
> caller doesn't know how to deal with a NULL (it expects
> an INT16, for example).
Really? That would be a caller bug, if it's calling a function
Martijn van Oosterhout wrote:
On Wed, May 03, 2006 at 11:02:26PM -0700, Don Y wrote:
(sigh) Sorry to be picking nits. I'm just trying to
sort out how to protect against folks making careless
mistakes in the future (e.g., forgetting STRICT in
the function declarations when adding a function to
Tom Lane wrote:
Don Y <[EMAIL PROTECTED]> writes:
Is there any way of mimicking the IS STRICT behavior
*without* declaring the function as "STRICT"?
Are you looking for PG_RETURN_NULL()? If not, this seems a bit
nonsensical.
No.
First, if the function is defined to return an INT16,
then re
On Wed, May 03, 2006 at 11:02:26PM -0700, Don Y wrote:
> (sigh) Sorry to be picking nits. I'm just trying to
> sort out how to protect against folks making careless
> mistakes in the future (e.g., forgetting STRICT in
> the function declarations when adding a function to
> a database, etc)
Unfor
Don Y <[EMAIL PROTECTED]> writes:
> Is there any way of mimicking the IS STRICT behavior
> *without* declaring the function as "STRICT"?
Are you looking for PG_RETURN_NULL()? If not, this seems a bit
nonsensical.
> Lastly, am I correct in assuming that the STRICT
> modifier only protect a functi
16 matches
Mail list logo
