Re: Function overloading - Mailing list pgsql-novice

From Robert B. Easter
Subject Re: Function overloading
Date
Msg-id 0012100922161N.00289@comptechnews
Whole thread Raw
In response to Re: Function overloading  (Rynell Wesson <rwesson@cs.utexas.edu>)
List pgsql-novice
I've used a different casting syntax in SQL and PL/SQL (maybe you can try it):

SELECT foo('This is a string'::TEXT, 'This is a string'::TEXT);
SELECT foo('5'::INTEGER, '5'::INTEGER);


On Sunday 10 December 2000 01:51, Rynell Wesson wrote:
> On Sat, 9 Dec 2000, Tom Lane wrote:
> > Rynell Wesson <rwesson@cs.utexas.edu> writes:
> > > I keep getting the following error.
> > >
> > > psql:fdm:11: ERROR:  Function 'foo(unknown, unknown)' does not exist
> >
> > That could only come out when you write
> >
> >     select foo('string', 'string')
> >
> > and there is more than one possible candidate for foo().  The thing to
> > realize here is that Postgres does not assume that 'string' is a string.
> > Rather, it is a literal of as-yet-undetermined type.  If the particular
> > foo() function can be identified uniquely, then the system can infer
> > what type the unknown-type literal should be converted to.  Otherwise
> > it gets unhappy.
> >
> > In the example you've given,
> >     select foo(text('testing'), text('testing'));
> > ought to work fine to select the foo(text,text) function.  It does work
> > when I try it.  I wonder whether you are looking for the problem in the
> > wrong place.  Is it possible that the error report is actually coming
> > from trying to evaluate the function body?  What did you put in the
> > body, anyway?
>
> Unless I missed something, the function bodies do not appear to be the
> problem.  They have both been tested seperately without any problems.  It
> seems as if there is a problem with the compiler's semantic analysis
> phase.  Here are the function bodies.
>
> CREATE FUNCTION foo(text, text)
>   RETURNS NUMERIC AS '
>
>   DECLARE
>
>   p_qstn ALIAS FOR $1;
>   p_fname ALIAS FOR $2;
>
>   v_fid foq.fid%TYPE;
>   v_qid foq.qid%TYPE;
>   v_qnum foq.qnum%TYPE;
>
>   BEGIN
>
>     SELECT id INTO v_qid FROM qwert WHERE qstn = p_qstn;
>     SELECT id, nqs INTO v_fid, v_qnum FROM farm
>       WHERE name = p_fname;
>     v_qnum := v_qnum + 1;
>
>     UPDATE farm SET nqs = nqs + 1
>       WHERE name = p_fname;
>
>     INSERT INTO foq (fid, qid, qnum)
>       VALUES (v_fid, v_qid, v_qnum);
>
>     RETURN 0;
>
>   END;'
>   LANGUAGE 'plpgsql';
>
>
> CREATE FUNCTION foo(int4, int4)
>   RETURNS NUMERIC AS '
>
>   DECLARE
>
>   p_qid ALIAS FOR $1;
>   p_fid ALIAS FOR $2;
>
>   v_qnum foq.qnum%TYPE;
>
>   BEGIN
>
>     SELECT nqs INTO v_qnum FROM farm WHERE id = p_fid;
>     v_qnum := v_qnum + 1;
>
>     UPDATE farm SET nqs = nqs + 1
>       WHERE id = p_fid;
>
>     INSERT INTO foq (fid, qid, qnum)
>       VALUES (p_fid, p_qid, v_qnum);
>
>     RETURN 0;
>
>   END;'
>   LANGUAGE 'plpgsql';
>
> > BTW, Postgres 7.1 has been tweaked to be more willing to assume that
> > an unidentified-type literal is a string datatype, when it can't make
> > a unique decision otherwise.  So in 7.1 you'll get the result you
> > expected from "select foo('string', 'string')".  But the form with
> > the explicit casts should have worked anyway.
> >
> >             regards, tom lane

--
-------- Robert B. Easter  reaster@comptechnews.com ---------
- CompTechNews Message Board   http://www.comptechnews.com/ -
- CompTechServ Tech Services   http://www.comptechserv.com/ -
---------- http://www.comptechnews.com/~reaster/ ------------

pgsql-novice by date:

Previous
From: Rynell Wesson
Date:
Subject: Re: Function overloading
Next
From: mwaples@optusnet.com.au
Date:
Subject: plpgsql question