"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this version is WIP - I have to clean comments, and will do some
> documentation. But I am sure, I am not able explain this feature in
> english well. Please, can some body help me with documentation? So
> now, plpgsql is more/less ruby :)
Applied with
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> sample: select mleast(variadic array[1,2,3,4,5]);
One other point here: in the patch as presently submitted, VARIADIC
can't be an unreserved keyword, but it seems to be enough to make it a
col_name_keyword. Some preliminary testing says that that does
2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
>>> Are you intending to change this right now and resubmit, or is it
>>> work for later?
>
>> I prefer separate it to other patch.
>
> It seems a fairly important part o
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
>> Are you intending to change this right now and resubmit, or is it
>> work for later?
> I prefer separate it to other patch.
It seems a fairly important part of the feature, especially given the
connection to
2008/7/14 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> sample: select mleast(variadic array[1,2,3,4,5]);
>
> Note this would also address Jeff's complaint about not being able to
> pass zero variadic parameters:
>
> select mleast(variadic array[]::int[]);
>
> Looks
Jeff Davis <[EMAIL PROTECTED]> writes:
> I don't have a strong opinion, but allowing zero-argument variadic
> function calls -- and therefore causing foo(variadic int[]) and
> foo(variadic text[]) to conflict -- makes more sense than requiring one
> argument.
I hadn't even thought about that point
On Sun, 2008-07-13 at 12:32 -0400, Tom Lane wrote:
> >> Also, it doesn't seem to allow calls to a variadic function with zero
> >> arguments, e.g. "mleast()". I think this should be allowed.
>
> > It's not possible for all cases, because empty array have be typed
> > array still. But for non polym
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> sample: select mleast(variadic array[1,2,3,4,5]);
Note this would also address Jeff's complaint about not being able to
pass zero variadic parameters:
select mleast(variadic array[]::int[]);
Looks a bit ugly but the type is specified, so it would wor
2008/7/14 Florian G. Pflug <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>>
>>> One issue that just occurred to me: what if a variadic function wants to
>>> turn around and call another variadic function, passing the same array
>>> argument on to the second one? This is closely akin
>>> to the pro
Pavel Stehule wrote:
One issue that just occurred to me: what if a variadic function
wants to turn around and call another variadic function, passing
the same array argument on to the second one? This is closely akin
to the problem faced by C "..." functions, and the solutions are
pretty ugly
2008/7/13 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
>>> Also, it doesn't seem to allow calls to a variadic function with zero
>>> arguments, e.g. "mleast()". I think this should be allowed.
>
>> It's not possible for all
>
> As far as the "variadic int" versus "variadic int[]" business, I'm
> starting to agree with Pavel that "variadic int[]" offers less potential
> for confusion. In particular, it seems to make it more obvious for the
> function author that the argument he receives is an array. Also, the
> other
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
>> Also, it doesn't seem to allow calls to a variadic function with zero
>> arguments, e.g. "mleast()". I think this should be allowed.
> It's not possible for all cases, because empty array have be typed
> arr
2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
> On Sun, 2008-07-13 at 07:52 +0200, Pavel Stehule wrote:
>> you checked second or third variant? There are two variants still.
>
> Sorry for being unclear. Those comments regarded patch v2.2.1. The bug
> is in pg_function_is_visible().
it's bug, I'll fix i
2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
> 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(
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);
> $$ LANGUAGE SQL;
>
I don't have a
On Sat, 2008-07-12 at 23:06 -0700, Jeff Davis wrote:
> 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
On Sun, 2008-07-13 at 07:52 +0200, Pavel Stehule wrote:
> you checked second or third variant? There are two variants still.
Sorry for being unclear. Those comments regarded patch v2.2.1. The bug
is in pg_function_is_visible().
Additionally, I'd like to see support for calling variadic functions
Hello
2008/7/13 Jeff Davis <[EMAIL PROTECTED]>:
> On Thu, 2008-06-26 at 17:03 +0200, Pavel Stehule wrote:
>> this is third variant with variadic argumen as scalar. But I still
>> strongly prefer second variant with conformance declared variadic
>> array with used array variable.
>
you checked sec
On Thu, 2008-06-26 at 17:03 +0200, Pavel Stehule wrote:
> this is third variant with variadic argumen as scalar. But I still
> strongly prefer second variant with conformance declared variadic
> array with used array variable.
This version allows you to declare two functions "foo(variadic numeric)
2008/7/4 Simon Riggs <[EMAIL PROTECTED]>:
>
> On Mon, 2008-06-23 at 15:13 +0200, Pavel Stehule wrote:
>
>> this patch enhance current syntax of CREATE FUNCTION statement. It
>> allows creating functions with variable number of arguments. This
>> version is different than last my patches. It doesn't
On Mon, 2008-06-23 at 15:13 +0200, Pavel Stehule wrote:
> this patch enhance current syntax of CREATE FUNCTION statement. It
> allows creating functions with variable number of arguments. This
> version is different than last my patches. It doesn't need patching
> PL. Basic idea is transformation
2008/6/25 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create funct
2008/6/25 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create funct
Pavel Stehule wrote:
I afraid so Java syntax isn't good inspiration
http://www.java-tips.org/java-se-tips/java.lang/using-the-varargs-language-feature.html
http://www.clanproductions.com/java5.html
they use symbol ... like specific synonym to [].
public Method getMethod(String name, Class...
2008/6/25 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create funct
2008/6/25 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create funct
2008/6/25 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create funct
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Your point about the syntax is good though. It would be better if
>>> the syntax were like
>>> create function foo (a text, variadic b int[])
>>> or maybe even better
>>> create function foo (a text, variadic b int)
> I don't see
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);
$$ LANGUAGE SQL;
Regards
Pavel Stehule
2008/6/24 Tom Lane <[EMAIL PROTECTED]>:
> Andrew Dunstan <[EMAIL PRO
2008/6/24 Tom Lane <[EMAIL PROTECTED]>:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> But if I have
>> foo( a text, b int[])
>> it looks odd if both these calls are legal:
>> foo('a',1,2,3,)
>> foo('a',ARRAY[1,2,3])
>> which I understand would be the case with the current patch.
>
> Maybe I
2008/6/23 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> And what about a function that takes 2 arrays as arguments?
only last argument is evaluated as variadic
so function
create or replace function foo(a int[], b int[]) ... variadic
is called
select foo(array[1,2,3], 1,2,3,4,5,6)
>
> This propos
2008/6/24 Andrew Dunstan <[EMAIL PROTECTED]>:
>
>
> Tom Lane wrote:
>>
>> Your point about the syntax is good though. It would be better if
>> the syntax were like
>>
>>create function foo (a text, variadic b int[])
>>
>> or maybe even better
>>
>>create function foo (a text, varia
Tom Lane wrote:
Your point about the syntax is good though. It would be better if
the syntax were like
create function foo (a text, variadic b int[])
or maybe even better
create function foo (a text, variadic b int)
since (a) this makes it much more obvious to the reader wh
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> But if I have
> foo( a text, b int[])
> it looks odd if both these calls are legal:
> foo('a',1,2,3,)
> foo('a',ARRAY[1,2,3])
> which I understand would be the case with the current patch.
Maybe I misunderstand what is supposed to happen, but I be
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What would you consider "proper and full support"?
I don't know. But this doesn't feel like it.
That's a fairly weak argument for rejecting a patch that provides a
feature many people have asked
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What would you consider "proper and full support"?
>
> I don't know. But this doesn't feel like it.
That's a fairly weak argument for rejecting a patch that provides a
feature many people have asked for.
I thought the patch was pret
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
This proposal strikes me as half-baked. Either we need proper and full
support for variadic functions, or we don't, but I don't think we need
syntactic sugar like the above (or maybe in this case it's really
syntactic saccharine).
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This proposal strikes me as half-baked. Either we need proper and full
> support for variadic functions, or we don't, but I don't think we need
> syntactic sugar like the above (or maybe in this case it's really
> syntactic saccharine).
What would yo
Pavel Stehule wrote:
Hello
this patch enhance current syntax of CREATE FUNCTION statement. It
allows creating functions with variable number of arguments. This
version is different than last my patches. It doesn't need patching
PL. Basic idea is transformation of real arguments (related to
dec
40 matches
Mail list logo
