Re: plpgsql: defuault parameters and constant function parameters
От | Tom Lane |
---|---|
Тема | Re: plpgsql: defuault parameters and constant function parameters |
Дата | |
Msg-id | 13701.1188433163@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | plpgsql: defuault parameters and constant function parameters ("Roger Moloney" <ramoloney@hotmail.com>) |
Ответы |
Re: plpgsql: defuault parameters and constant function parameters
|
Список | pgsql-interfaces |
"Roger Moloney" <ramoloney@hotmail.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
В списке pgsql-interfaces по дате отправления: