Re: proposal: generic function, constructor function - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: generic function, constructor function
Date
Msg-id 162867790801201420x9eed0cew181c9e376d89062e@mail.gmail.com
Whole thread Raw
In response to Re: proposal: generic function, constructor function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello

>
> The different-numbers-of-arguments bit is what I'm objecting to.
> Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
> etc, and you're done without breaking anything else.
>

I found simple solution, it uses ANY, but number of necessary ANY
arguments is generated dynamically:

FuncCandidateList
FuncnameGetCandidates(List *names, int nargs)
{       FuncCandidateList resultList = NULL;       char       *schemaname;....        /* anyparams has unlimeted
pronargs,we cannot check it */
 
               if (pronargs == 1 && procform->proargtypes.values[0]
== ANYPARAMSOID)                       generic_function = true;
               /* Ignore if it doesn't match requested argument count */               else if (nargs >= 0 && pronargs
!=nargs)                       continue;
 

....             /*                * Okay to add it to result list                */
               if (!generic_function)               {                       newResult = (FuncCandidateList)
                 palloc(sizeof(struct
 
_FuncCandidateList) - sizeof(Oid)                                          + pronargs * sizeof(Oid));
   newResult->pathpos = pathpos;                       newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs= pronargs;                       memcpy(newResult->args, procform->proargtypes.values,
                pronargs * sizeof(Oid));
 
                       newResult->next = resultList;                       resultList = newResult;               }
        else               {                       /* generic function hasn't own params, but we
 
know numbers and                        * we can use ANY type.                        */                       int
i;
                       newResult = (FuncCandidateList)                               palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid)                                          + nargs * sizeof(Oid));
newResult->pathpos = pathpos;                       newResult->oid = HeapTupleGetOid(proctup);
newResult->nargs= nargs;                       for (i = 0; i < nargs; i++)
newResult->args[i]= ANYOID;
 
                       newResult->next = resultList;                       resultList = newResult;               }

It is more simpler than I though and it works. With this technique I
don't need some mentioned restriction.

ANYPARAMS is only syntactic sugar for  n x ANY

What do you thing about it, please?

Regards
Pavel Stehule




> > we can use partial unique index, if it is possible - I didn't test it.
>
> It's not --- partial indexes on system catalogs are not supported, and
> pg_proc is certainly one catalog that that restriction will never be
> relaxed for.  (How you going to execute a predicate without doing
> function lookups?)  I don't believe that the constraint could be
> expressed as a partial index predicate anyway --- how will you say
> that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
> don't?
>
>                         regards, tom lane
>


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: message string fixes
Next
From: Alvaro Herrera
Date:
Subject: Re: message string fixes