Joe Conway <m...@joeconway.com> writes:
> Actually, I had in mind something like:
> 8<---------------------
> int i;
> int numargs;
> int *argtypes;
> numargs = PG_NARGS();
> argtypes = palloc(numargs * sizeof(int));
> for (i = 0; i < numargs; i++)
> argtypes[i] = get_fn_expr_argtype(fcinfo->flinfo, i);
> if ((numargs == 4 || numargs == 5) &&
> argtypes[0] == TEXTOID &&
> argtypes[1] == TEXTOID &&
> argtypes[2] == INT4OID &&
> argtypes[3] == BOOLOID)
> {
> [...]
> }
> else if ((numargs == 3 || numargs == 4) &&
> argtypes[0] == TEXTOID &&
> argtypes[1] == INT4OID &&
> argtypes[2] == BOOLOID)
> {
> [...]
> 8<---------------------
> etc.
If the set of allowed argument-type combinations is so easily enumerable,
I don't understand why this is being done at all. Create a separate SQL
function for each combination. You can still let the called C functions
call a common implementation routine if that's helpful.
However, this might all be moot in view of Merlin's objection. It is
definitely completely uncool to have both of these:
> public | dblink | SETOF anyelement | text, anyelement | normal
> public | dblink | SETOF record | text, boolean | normal
It's quite unclear which one will get called for cases like, say, second
argument is a domain over boolean. And even if the second arg is just a
boolean, maybe the user wanted the first case --- how will he get that
behavior, if so? These need to have different names, and that might well
help resolve the implementation-level issue...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
