On 18/01/2008, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
> > I propose two kinds of functions:
>
> > a) generic functions - this function allows any params without any
> > implicit casting (it can implemented only in C language).
>
> Can't you do that already with ANYELEMENT, or at the worst ANY?
Anyelement is related with casting to common type.
postgres=# create or replace function fx(anyelement, anyelement)
returns text as $$begin return 'ahoj'; end; $$ language plpgsql;
CREATE FUNCTION
postgres=# select fx(1,'a');
ERROR: invalid input syntax for integer: "a"
postgres=# select fx(1,'a');
I would to have independent parameters and move type checking to
function. Then I don't need register function exactly and then I can
have different numbers of arguments. It's similar like C varargs
functions so now I cannot effectively implement printf function,
because all parameters are casted to varchar.
Using any is broken. ?
postgres=# create or replace function fx1(any) returns text as $$begin
return 'ahoj'; end; $$ language plpgsql;
ERROR: syntax error at or near "any"
LINE 1: create or replace function fx1(any) returns text as $$begin ... ^
>
> > It allows unspecified number of params
> > without parser changes.
>
> Why is that a good idea (and if you think it won't take parser changes,
> you're wrong)?
Of course. Implementation needs some changes in parser. But new
generic function doesn't need it. With generic functions some xml
functions could exists outside parser. And it's simple tool for
constructors.
>
> > Limits: only one function with specified name can exists in schema.
>
> This is why it's a bad idea. Please note that the unique index on
> pg_proc cannot enforce that, even if we wanted such a restriction.
>
we can use partial unique index, if it is possible - I didn't test it.
Regards
Pavel Stehule
> regards, tom lane
>