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: