Skip site navigation (1) Skip section navigation (2)

Re: plpgsql: defuault parameters and constant function parameters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Roger Moloney" <ramoloney(at)hotmail(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: plpgsql: defuault parameters and constant function parameters
Date: 2007-08-30 00:19:23
Message-ID: 13701.1188433163@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
"Roger Moloney" <ramoloney(at)hotmail(dot)com> writes:
> Having just done the first draft of a large migration from informix to 
> postgres, I wanted to point out that the migration was hugely complicated by 
> postgres inability to define default parameters

You can get that effect using function name overloading.  For instance

create function f(x int, y int) ...

create function f(x int) ... as 'select f(x, 1)' ...

It's easier if the defaultable parameters are at the end, but I rather
wonder how your informix system is disambiguating the calls either
with a signature like that.  If you leave off just one of the two
defaultable parameters, how does it know which?

>       I dont want to make them output parameters as they are not output 
> parameters. I am returning different output parameters. However it would be 
> great if I could modify (and not pass back) the value of a input parameter. 

Just use a differently named local variable, perhaps?  Actually, because
of the scoping rules it seems to me to work fine even if they have the
same name:

regression=# create function ff(f1 int) returns int as $$
declare f1 int := coalesce(f1, 1);
begin
  return f1;
end$$ language plpgsql;
CREATE FUNCTION
regression=# select ff(3);
 ff 
----
  3
(1 row)

regression=# select ff(null);
 ff 
----
  1
(1 row)

> Any chance of allowing input parameters to be modified within the function 
> body ?

That check is there to prevent mistakes, and I think it's a good one.

			regards, tom lane

In response to

Responses

pgsql-interfaces by date

Next:From: Jeroen T. VermeulenDate: 2007-08-30 08:57:11
Subject: Re: Problem with character encodings.
Previous:From: Korumilli, Bala S (GE Healthcare)Date: 2007-08-29 06:59:52
Subject: Problem with character encodings.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group