On Mon, Jul 6, 2015 at 9:35 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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...
yup, and at least one case now fails where previously it ran through:
postgres=# select * from dblink('a', 'b', 'c');
ERROR: function dblink(unknown, unknown, unknown) is not unique
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
