On 18/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote: > "Pavel Stehule" <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster