Thread

Re: [HACKERS] A small problem with the new inet and cidr types

Tom Lane <tgl@sss.pgh.pa.us> — 1998-11-02T15:50:38Z

darcy@druid.net (D'Arcy J.M. Cain) writes:
> OK, there are more problems.  If you apply the following patch to the
> regression tests you will crash the backend in a number of places.

Yipes!

I must withdraw my prior opinion that we should shoehorn in a repair to
the INET datatypes for this case.  It's clear that we have a wideranging
problem that ought to be fixed more globally.  But presumably it's
been there for quite a while, and we didn't know it; therefore it's not
critical enough to hold up the release.

My guess is that maybe this should not be fixed in the individual
datatypes at all; instead the generic function and operator code should
be modified so that if any input value is NULL, then NULL is returned as
the result without ever calling the datatype-specific code.

There might be specific operators for which this is not the right
behavior (although none spring to mind immediately).  In that case,
I think the best bet would be to have a per-operator flag, defaulting
to OFF, which could be turned on for those specific operators that are
prepared to cope with null inputs.

Thoughts?

			regards, tom lane

Re: [HACKERS] A small problem with the new inet and cidr types

D'Arcy J.M. Cain <darcy@druid.net> — 1998-11-02T18:06:38Z

Thus spake Tom Lane
> My guess is that maybe this should not be fixed in the individual
> datatypes at all; instead the generic function and operator code should
> be modified so that if any input value is NULL, then NULL is returned as
> the result without ever calling the datatype-specific code.

Could it be tied to the return type?  IOW, functions or operators
that return bool return FALSE, text return "", etc.

> There might be specific operators for which this is not the right
> behavior (although none spring to mind immediately).  In that case,
> I think the best bet would be to have a per-operator flag, defaulting
> to OFF, which could be turned on for those specific operators that are
> prepared to cope with null inputs.

Obviously that will have to wait for 6.5 since it requires an initdb
to add the field.  Do we want to wait that long?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

RE: [HACKERS] A small problem with the new inet and cidr types

Taral <taral@mail.utexas.edu> — 1998-11-02T18:31:23Z

> My guess is that maybe this should not be fixed in the individual
> datatypes at all; instead the generic function and operator code should
> be modified so that if any input value is NULL, then NULL is returned as
> the result without ever calling the datatype-specific code.

AFAICT, the function code returns blank when the input is NULL, regardless
of the function definition... this came up before when someone tried to
extend the functions and found that func(NULL) called func, but disregarded
the return value...

Taral

Re: [HACKERS] A small problem with the new inet and cidr types

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-11-02T18:35:43Z

> Thus spake Tom Lane
> > My guess is that maybe this should not be fixed in the individual
> > datatypes at all; instead the generic function and operator code should
> > be modified so that if any input value is NULL, then NULL is returned as
> > the result without ever calling the datatype-specific code.
> 
> Could it be tied to the return type?  IOW, functions or operators
> that return bool return FALSE, text return "", etc.
> 
> > There might be specific operators for which this is not the right
> > behavior (although none spring to mind immediately).  In that case,
> > I think the best bet would be to have a per-operator flag, defaulting
> > to OFF, which could be turned on for those specific operators that are
> > prepared to cope with null inputs.
> 
> Obviously that will have to wait for 6.5 since it requires an initdb
> to add the field.  Do we want to wait that long?

The only thing I can add here is to look at the other functions, and do
what they do.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] A small problem with the new inet and cidr types

D'Arcy J.M. Cain <darcy@druid.net> — 1998-11-02T19:36:04Z

Thus spake Bruce Momjian
> The only thing I can add here is to look at the other functions, and do
> what they do.

Uh, they crash the backend.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] A small problem with the new inet and cidr types

D'Arcy J.M. Cain <darcy@druid.net> — 1998-11-02T19:41:46Z

Thus spake Taral
> > My guess is that maybe this should not be fixed in the individual
> > datatypes at all; instead the generic function and operator code should
> > be modified so that if any input value is NULL, then NULL is returned as
> > the result without ever calling the datatype-specific code.
> 
> AFAICT, the function code returns blank when the input is NULL, regardless
> of the function definition... this came up before when someone tried to
> extend the functions and found that func(NULL) called func, but disregarded
> the return value...

Well that sure fits with my observations.  Sure seems wrong though.  We
should either use the return value or don't call the function in the
first place.  I vote for the latter even though I have spent the time
fixing inet.  It seems like the proper method.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] A small problem with the new inet and cidr types

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-11-02T19:48:29Z

> Thus spake Bruce Momjian
> > The only thing I can add here is to look at the other functions, and do
> > what they do.
> 
> Uh, they crash the backend.  :-)

Oh.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] A small problem with the new inet and cidr types

Jan Wieck <jwieck@debis.com> — 1998-11-03T09:21:06Z

>
> Thus spake Taral
> > > My guess is that maybe this should not be fixed in the individual
> > > datatypes at all; instead the generic function and operator code should
> > > be modified so that if any input value is NULL, then NULL is returned as
> > > the result without ever calling the datatype-specific code.
> >
> > AFAICT, the function code returns blank when the input is NULL, regardless
> > of the function definition... this came up before when someone tried to
> > extend the functions and found that func(NULL) called func, but disregarded
> > the return value...
>
> Well that sure fits with my observations.  Sure seems wrong though.  We
> should either use the return value or don't call the function in the
> first place.  I vote for the latter even though I have spent the time
> fixing inet.  It seems like the proper method.

    Not  calling  a  function  if  one of it's arguments is NULL?
    Isn't NULL a legal value?

    I know that the function manager interface is  damned  stupid
    in  the  case of NULL's. Some of the interface functions pass
    isNull as in/out value and some do not. And the in value only
    tells if any of the arguments are NULL, not which of them. It
    hit me when building PL/pgSQL and PL/Tcl.

    Let's redesign the function call interface  and  define  that
    any  function  has  to handle NULL arguments properly. Yes, I
    know what that means :-).


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

Re: [HACKERS] A small problem with the new inet and cidr types

Hannu Krosing <hannu@trust.ee> — 1998-11-03T11:07:44Z

Jan Wieck wrote:
> 
>     Not  calling  a  function  if  one of it's arguments is NULL?
>     Isn't NULL a legal value?
> 
>     I know that the function manager interface is  damned  stupid
>     in  the  case of NULL's. Some of the interface functions pass
>     isNull as in/out value and some do not. And the in value only
>     tells if any of the arguments are NULL, not which of them. It
>     hit me when building PL/pgSQL and PL/Tcl.
> 
>     Let's redesign the function call interface  and  define  that
>     any  function  has  to handle NULL arguments properly. Yes, I
>     know what that means :-).

An easier way would be _not_ to call a function with NULL arguments, 
_unless_ it declares that it can handle them.

It would probably do the right thing in many (most?) places.

But we do need to redesign not only the function _call_ interface, but
most likely also the function _definition_ mechanisms as well.

On the whole I would like the functions to be more object-like, 
meaning that they should have methods (metadata) that could tell 
things about them. In addition to an method that tells if the 
function can take NULL as an argument and in what positions, 
I envision we could also use a method that would tell the max print 
length and other "field" attribute of the function return value given 
the attributes of function arguments. For example we would be able to 
determine that the max length of concatenating varchar(5) and varchar(7) 
is varchar(12) and not a varchar of infinite length as we have to 
assume now.

Is'nt PostgreSQL supposed to be somewhat OO DBMS ? 

----------
Hannu

Re: [HACKERS] A small problem with the new inet and cidr types

D'Arcy J.M. Cain <darcy@druid.net> — 1998-11-03T12:24:05Z

Thus spake Jan Wieck
> > Well that sure fits with my observations.  Sure seems wrong though.  We
> > should either use the return value or don't call the function in the
> > first place.  I vote for the latter even though I have spent the time
> > fixing inet.  It seems like the proper method.
> 
>     Not  calling  a  function  if  one of it's arguments is NULL?
>     Isn't NULL a legal value?

Sure but what is the reasonable thing to do if we perform a function
on a null?  Let's take the inet/cidr functions that started this.  If
i is a null field then these seem reasonable conversions.

  host(i) ==>  null
  network(i) ==> null
  broadcast(i) ==> null

...etc.

There may be cases where a function of a null is not null as some people
have pointed out but so far no one has come up with a practical example.

I suggested that the actual return value could depend on the return
type.  The only reason I suggested that was for the case of boolean
returns.  I see some merit in being able to decide in my select whether
or not to include rows where one or more operators is null but even
there it is probably of marginal utility.  If it is absolutely essential
to display every row then you can always constrain the field to NOT
NULL and use a marker value for null.

>     Let's redesign the function call interface  and  define  that
>     any  function  has  to handle NULL arguments properly. Yes, I
>     know what that means :-).

Well, let's hurry up and decide this so I know whether or not to
clean out my local patches to inet/cidr.  :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] A small problem with the new inet and cidr types

Hannu Krosing <hannu@trust.ee> — 1998-11-03T13:09:12Z

D'Arcy J.M. Cain wrote:
> 
> There may be cases where a function of a null is not null as some people
> have pointed out but so far no one has come up with a practical example.

isnull(field)

is_any_null(field1,field2,field3)

are_all_nulls(field1,field2,field3)

value_or_default(NULL,defaultvalue)

---------
Hannu

Re: [HACKERS] A small problem with the new inet and cidr types

D'Arcy J.M. Cain <darcy@druid.net> — 1998-11-03T13:53:16Z

Thus spake Hannu Krosing
> D'Arcy J.M. Cain wrote:
> > There may be cases where a function of a null is not null as some people
> > have pointed out but so far no one has come up with a practical example.
> 
> isnull(field)
> 
> is_any_null(field1,field2,field3)
> 
> are_all_nulls(field1,field2,field3)
> 
> value_or_default(NULL,defaultvalue)

I meant in the specific type functions.  These functions seem like they
can easily be handled at a higher level and still never call the type
function code.  IOW, if these functions are considered useful, they
should be implemented at the function dispatch level.

That last one seems particularly useful to me and, in fact, could handle
the issue of requiring functions to handle nulls all by itself.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] A small problem with the new inet and cidr types

Bruce Momjian <maillist@candle.pha.pa.us> — 1998-11-03T16:38:03Z

>     Not  calling  a  function  if  one of it's arguments is NULL?
>     Isn't NULL a legal value?
> 
>     I know that the function manager interface is  damned  stupid
>     in  the  case of NULL's. Some of the interface functions pass
>     isNull as in/out value and some do not. And the in value only
>     tells if any of the arguments are NULL, not which of them. It
>     hit me when building PL/pgSQL and PL/Tcl.
> 
>     Let's redesign the function call interface  and  define  that
>     any  function  has  to handle NULL arguments properly. Yes, I
>     know what that means :-).
> 

Added to TODO list:

	* redesign the function call interface to handle NULLs better


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [HACKERS] A small problem with the new inet and cidr types

Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-11-04T02:50:46Z

> * redesign the function call interface to handle NULLs better

I was planning on looking at this for v6.5, at least in the context of
trying to solve the problem of returning NULL for pass-by-value types.

We should have some discussion of pass-by-value vs. pass-by-reference
and whether it is worth having both mechanisms for common data types. As
it is, functions which return int2 or int4 cannot return NULL because
there is no way to represent that with these types. I was thinking of
implementing true smallint/integer pass-by-reference types to clean this
up.

                      - Tom

Re: [HACKERS] A small problem with the new inet and cidr types

Jan Wieck <jwieck@debis.com> — 1998-11-04T10:41:24Z

>
> > * redesign the function call interface to handle NULLs better
>
> I was planning on looking at this for v6.5, at least in the context of
> trying to solve the problem of returning NULL for pass-by-value types.
>
> We should have some discussion of pass-by-value vs. pass-by-reference
> and whether it is worth having both mechanisms for common data types. As
> it is, functions which return int2 or int4 cannot return NULL because
> there is no way to represent that with these types. I was thinking of
> implementing true smallint/integer pass-by-reference types to clean this
> up.

    Actually  they  can  -  but  only  if  they  take exactly one
    argument.  fmgr_c()  calls  those  ones  with  an  additional
    isNull bool pointer.

    The  mess  is,  that we have different entry points to call a
    function, some of them pass information about NULL  and  some
    not.  What I had in mind was to finally have one single entry
    point that handles NULL for any argument and for  the  return
    value.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #