Skip site navigation (1) Skip section navigation (2)

Re: variadic function support

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: variadic function support
Date: 2008-07-13 06:06:04
Message-ID: 1215929164.11352.55.camel@jdavis (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, 2008-06-24 at 17:10 +0200, Pavel Stehule wrote:
> Hello
> this version implements syntax based on argmodes.
> CREATE FUNCTION mleast(variadic numeric[]) RETURNS numeric AS $$
>     SELECT min($1[i])
>        FROM generate_subscripts($1,1) g(i);

I don't have a strong opinion about whether the variadic argument is
declared as an array or scalar, so I am posting my comments about this
version of the patch as well.

This version also has a problem when declaring two functions "foo(int)"
and "foo(variadic int[])". In this version, the declaration is allowed
but the backend crashes when the function is called.

The variable "transform_variadic" should have some kind of comment. It
seems to be there to distinguish between when you're looking for a
candidate function for a function call, and when you're looking for a
candidate function for, e.g., CREATE FUNCTION. It's a little hard to
follow, and is probably the cause for the aformentioned crash.

Also, it doesn't seem to allow calls to a variadic function with zero
arguments, e.g. "mleast()". I think this should be allowed.

I suggest the following error message rewording:
"variadic argument isn't an array" should be something like: "variadic
argument must be an array".

	Jeff Davis

In response to


pgsql-patches by date

Next:From: Jeff DavisDate: 2008-07-13 06:11:56
Subject: Re: variadic function support
Previous:From: Pavel StehuleDate: 2008-07-13 05:52:11
Subject: Re: variadic function support

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group