Function with default value not replacing old definition of the function
Hi,
Testcase: (8.4 CVS head)
====================
CREATE OR REPLACE FUNCTION myfunc(y int)
RETURNS INTEGER AS $$
select 100;
$$ language sql;
CREATE OR REPLACE FUNCTION myfunc(y int, x integer DEFAULT 100)
RETURNS INTEGER AS $$
select 200;
$$ language sql;
select myfunc(10);
myfunc
----------
100
(1 row)
When create the same function again by added one default value, while
calling the function old function getting called.
It seems that, function with defval not making any sense, if we want to call
the new function then we need to pass defval as well.
select myfunc(10,10);
myfunc
----------
200
(1 row)
I think second function should replace the old definition of the function,
inputs ?
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
Rushabh Lathia wrote:
Hi,
Testcase: (8.4 CVS head)
====================CREATE OR REPLACE FUNCTION myfunc(y int)
RETURNS INTEGER AS $$
select 100;
$$ language sql;CREATE OR REPLACE FUNCTION myfunc(y int, x integer DEFAULT 100)
RETURNS INTEGER AS $$
select 200;
$$ language sql;select myfunc(10);
myfunc
----------
100
(1 row)When create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want to
call the new function then we need to pass defval as well.
Hmm, good point, but I'm not sure that replacing the old function is
always right. For example, someone recently requested being able to say
select myfunc(10, DEFAULT);
so there would be some value to having both variants.
Do you have any comparisons with other systems (Oracle?) or other
programming languages?
On Thu, Dec 11, 2008 at 12:33 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
Rushabh Lathia wrote:
Hi,
Testcase: (8.4 CVS head)
====================CREATE OR REPLACE FUNCTION myfunc(y int)
RETURNS INTEGER AS $$
select 100;
$$ language sql;CREATE OR REPLACE FUNCTION myfunc(y int, x integer DEFAULT 100)
RETURNS INTEGER AS $$
select 200;
$$ language sql;select myfunc(10);
myfunc
----------
100
(1 row)When create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want to
call the new function then we need to pass defval as well.Hmm, good point, but I'm not sure that replacing the old function is always
right. For example, someone recently requested being able to sayselect myfunc(10, DEFAULT);
Hmm, good point.
so there would be some value to having both variants.
Do you have any comparisons with other systems (Oracle?) or other
programming languages?
Yes Oracle replace the old definition of the function with the new one.
--
Rushabh Lathia
www.EnterpriseDB.com
Hello
2008/12/11 Rushabh Lathia <rushabh.lathia@gmail.com>:
Hi,
Testcase: (8.4 CVS head)
====================CREATE OR REPLACE FUNCTION myfunc(y int)
RETURNS INTEGER AS $$
select 100;
$$ language sql;CREATE OR REPLACE FUNCTION myfunc(y int, x integer DEFAULT 100)
RETURNS INTEGER AS $$
select 200;
$$ language sql;select myfunc(10);
myfunc
----------
100
(1 row)
no, it's little bit different
Default is only stored parameter value. You created two functions with
two different signatures
myfunc(int)
myfunc(int, int)
when you created function, we cannot check defaults, because we don't
know if anybody use default or not. And when you call function, then
postgres prefer function with most similar function.
regards
Pavel Stehule
Show quoted text
When create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want to call
the new function then we need to pass defval as well.select myfunc(10,10);
myfunc
----------
200
(1 row)I think second function should replace the old definition of the function,
inputs ?Thanks,
Rushabh Lathia
www.EnterpriseDB.com
On Thu, Dec 11, 2008 at 12:40 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
Hello
2008/12/11 Rushabh Lathia <rushabh.lathia@gmail.com>:
Hi,
Testcase: (8.4 CVS head)
====================CREATE OR REPLACE FUNCTION myfunc(y int)
RETURNS INTEGER AS $$
select 100;
$$ language sql;CREATE OR REPLACE FUNCTION myfunc(y int, x integer DEFAULT 100)
RETURNS INTEGER AS $$
select 200;
$$ language sql;select myfunc(10);
myfunc
----------
100
(1 row)no, it's little bit different
Default is only stored parameter value. You created two functions with
two different signaturesmyfunc(int)
myfunc(int, int)when you created function, we cannot check defaults, because we don't
know if anybody use default or not. And when you call function, then
postgres prefer function with most similar function.
Ok, but what if I want to call a second function with the default values.
How can I call that function with default values?
regards
Pavel StehuleWhen create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want to
call
the new function then we need to pass defval as well.
select myfunc(10,10);
myfunc
----------
200
(1 row)I think second function should replace the old definition of the
function,
inputs ?
Thanks,
Rushabh Lathia
www.EnterpriseDB.com
--
Rushabh Lathia
www.EnterpriseDB.com
2008/12/11 Rushabh Lathia <rushabh.lathia@gmail.com>:
On Thu, Dec 11, 2008 at 12:40 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:Hello
when you created function, we cannot check defaults, because we don't
know if anybody use default or not. And when you call function, then
postgres prefer function with most similar function.Ok, but what if I want to call a second function with the default values.
How can I call that function with default values?
it isn't possible yet (without DEFAULT keyword support).
you have to drop myfunc(int) first.
regards
Pavel Stehule
Show quoted text
regards
Pavel StehuleWhen create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want to
call
the new function then we need to pass defval as well.select myfunc(10,10);
myfunc
----------
200
(1 row)I think second function should replace the old definition of the
function,
inputs ?Thanks,
Rushabh Lathia
www.EnterpriseDB.com--
Rushabh Lathia
www.EnterpriseDB.com
On Thu, Dec 11, 2008 at 12:59 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
2008/12/11 Rushabh Lathia <rushabh.lathia@gmail.com>:
On Thu, Dec 11, 2008 at 12:40 PM, Pavel Stehule <pavel.stehule@gmail.com
wrote:
Hello
when you created function, we cannot check defaults, because we don't
know if anybody use default or not. And when you call function, then
postgres prefer function with most similar function.Ok, but what if I want to call a second function with the default values.
How can I call that function with default values?it isn't possible yet (without DEFAULT keyword support).
Ohh Ok.
Thanks
you have to drop myfunc(int) first.
regards
Pavel Stehuleregards
Pavel StehuleWhen create the same function again by added one default value, while
calling the function old function getting called.It seems that, function with defval not making any sense, if we want
to
call
the new function then we need to pass defval as well.select myfunc(10,10);
myfunc
----------
200
(1 row)I think second function should replace the old definition of the
function,
inputs ?Thanks,
Rushabh Lathia
www.EnterpriseDB.com--
Rushabh Lathia
www.EnterpriseDB.com
--
Rushabh Lathia
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
no, it's little bit different
Default is only stored parameter value. You created two functions with
two different signatures
myfunc(int)
myfunc(int, int)
Yeah, we already bit this bullet with variadic functions --- if you have
myfunc(int, float)
myfunc(int, variadic float[])
then it's ambiguous which one should be used for call "myfunc(11, 12.5)".
The sanest answer I can see is "so, don't do that".
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Le 11 déc. 08 à 16:22, Tom Lane a écrit :
Yeah, we already bit this bullet with variadic functions --- if you
have
myfunc(int, float)
myfunc(int, variadic float[])
then it's ambiguous which one should be used for call "myfunc(11,
12.5)".
The sanest answer I can see is "so, don't do that".
Is there any warning level message at CREATE FUNCTION time for the
user/dba to know he's doing something... border line, almost shooting
himself in the foot?
I'd really welcome such an error message as a reminder to consider
seriously such a choice, which would not be though out in lot of cases
I suppose.
Regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAklBaQoACgkQlBXRlnbh1bn0VgCeJB+cBxX1tg1Qgn+MYaW6hS8O
ZX8An3niWwN4lFIbwuBZJ8mKgTBThm6o
=d4lp
-----END PGP SIGNATURE-----
Dimitri Fontaine <dfontaine@hi-media.com> writes:
The sanest answer I can see is "so, don't do that".
Is there any warning level message at CREATE FUNCTION time for the
user/dba to know he's doing something... border line, almost shooting
himself in the foot?
It's not that easy to produce a message that wouldn't be annoying noise.
In particular, it's hard to know whether functions in different schemas
would represent a problem or not.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 11 déc. 08 à 21:23, Tom Lane a écrit :
It's not that easy to produce a message that wouldn't be annoying
noise.
Something really amazing in PostgreSQL is the HINTs system in error
messages. Almost all the time thoses messages are focused and helping.
I'd see this warning as a HINT maybe:
WARNING: variadic function xxx(int, int[]) already exists
HINT: you would rather not to mask it
Well, I'm not sure WARNING HINTS are supported, it's more a way to
better explain the idea than anything else.
The bottom line was that I'm betting DBA would be happy to know and
wouldn't consider it annoying noise, and for the kind of "Please, I
know what I'm doing" DBAs, maybe some kind of warning_level GUC would
be desirable?
In particular, it's hard to know whether functions in different
schemas
would represent a problem or not.
I'd still vote in favor of the NOTICE/WARNING. I know I'd be happy to
have my beloved PostgreSQL being attentive and focused when maybe I'm
not. Even if this time I was.
Regards,
- --
dim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAklBfT8ACgkQlBXRlnbh1bnCaACfUoRUx+7sADsb13YqQR0PWAho
dKUAoJZCoIzxstAXMRa4VejFkjgdk2jk
=REM9
-----END PGP SIGNATURE-----