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: