Re: proposal: generic function, constructor function

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: generic function, constructor function
Date: 2008-01-20 22:20:13
Message-ID: 162867790801201420x9eed0cew181c9e376d89062e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-01-20 22:32:47 Re: message string fixes
Previous Message Teodor Sigaev 2008-01-20 22:18:09 Re: message string fixes