2010/2/24 Jeff Davis :
> On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
>> Pavel Stehule wrote:
>> > 2010/2/23 Bruce Momjian :
>> > >
>> > > Can someone work on a patch to implement the document changes suggested
>> > > below?
>> > >
>> >
>> > This patch is useless now. There are no this i
On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
> Pavel Stehule wrote:
> > 2010/2/23 Bruce Momjian :
> > >
> > > Can someone work on a patch to implement the document changes suggested
> > > below?
> > >
> >
> > This patch is useless now. There are no this issue now, because we
> > have in
Pavel Stehule wrote:
> 2010/2/23 Bruce Momjian :
> >
> > Can someone work on a patch to implement the document changes suggested
> > below?
> >
>
> This patch is useless now. There are no this issue now, because we
> have integrated true SQL parser.
Great, thanks.
--
Bruce Momjian ht
2010/2/23 Bruce Momjian :
>
> Can someone work on a patch to implement the document changes suggested
> below?
>
This patch is useless now. There are no this issue now, because we
have integrated true SQL parser.
Regards
Pavel
> ---
Can someone work on a patch to implement the document changes suggested
below?
---
Jeff Davis wrote:
> On Tue, 2009-09-15 at 10:51 +0200, Pavel Stehule wrote:
> > My renonc, please, try new patch. I forgot mark regproc.c fil
2009/10/8 David E. Wheeler :
> On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote:
>
>>> Committed with a fair amount of corner-case cleanup and refactoring.
>>
>> Woot! Thanks for all the hard work getting this committed (Pavel, Bernd,
>> Jeff, Tom and others)! I've been really looking forward to th
"David E. Wheeler" writes:
> On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote:
>> It's just the call notation -- the function only needs to know what
>> arguments it got for which parameters.
> So they're still ordered? I'm thinking of PL/Perl here
It's PL-independent as far as I know --- if you fi
On Oct 8, 2009, at 9:47 AM, Jeff Davis wrote:
It's just the call notation -- the function only needs to know what
arguments it got for which parameters.
So they're still ordered? I'm thinking of PL/Perl here…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Thu, 2009-10-08 at 09:44 -0700, David E. Wheeler wrote:
> +1 Thanks for getting this done.
>
> Now, does this just apply to PL/pgSQL? If so, what needs to happen for
> other PLs to support the feature?
It's just the call notation -- the function only needs to know what
arguments it got for w
On Oct 7, 2009, at 9:00 PM, Steve Prentice wrote:
Committed with a fair amount of corner-case cleanup and refactoring.
Woot! Thanks for all the hard work getting this committed (Pavel,
Bernd, Jeff, Tom and others)! I've been really looking forward to
this feature. Still hoping a solution i
On Oct 7, 2009, at 7:41 PM, Tom Lane wrote:
Pavel Stehule writes:
[ latest named-args patch ]
Committed with a fair amount of corner-case cleanup and refactoring.
Woot! Thanks for all the hard work getting this committed (Pavel,
Bernd, Jeff, Tom and others)! I've been really looking forwa
2009/10/8 Tom Lane :
> Pavel Stehule writes:
>> [ latest named-args patch ]
>
> Committed with a fair amount of corner-case cleanup and refactoring.
>
> regards, tom lane
>
Thank you
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Pavel Stehule writes:
> [ latest named-args patch ]
Committed with a fair amount of corner-case cleanup and refactoring.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
Jeff Davis writes:
>> We could possibly have VARIADIC throw an error if the
>> named argument that matches to the variadic parameter isn't the last
>> one, but I'm not sure that that's important rather than just pedantry.
> I would prefer such a restriction if it's reasonable to do.
[ pokes arou
On Wed, Oct 7, 2009 at 5:45 PM, Tom Lane wrote:
> I think what he was considering was the question of insisting that
> the VARIADIC keyword be attached to the named argument that actually
> matches the VARIADIC parameter. I think we could do it, but it might
> be a bit of a wart. I notice that r
On Wed, 2009-10-07 at 18:17 -0400, Tom Lane wrote:
> No, that's not what I'm driving at. The small change that I've got in
> mind would require you to say VARIADIC, but it would allow the function
> to match both the above call and
> foo(a AS x, c AS z, VARIADIC b AS y)
> when really z is the
2009/10/7 Jeff Davis :
> On Wed, 2009-10-07 at 23:32 +0200, Pavel Stehule wrote:
>> It's same as my origin ideas, much better formulated. It is ok for me.
>
> You indicated that there may be some implementation difficulty if the
> VARIADIC keyword is required for calling using named notation:
>
> h
2009/10/8 Tom Lane :
> Jeff Davis writes:
>> On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
>>> I think what he was considering was the question of insisting that
>>> the VARIADIC keyword be attached to the named argument that actually
>>> matches the VARIADIC parameter.
>
>> It seems strange
Jeff Davis writes:
> On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
>> I think what he was considering was the question of insisting that
>> the VARIADIC keyword be attached to the named argument that actually
>> matches the VARIADIC parameter.
> It seems strange to me if we have a situation
On Wed, 2009-10-07 at 17:45 -0400, Tom Lane wrote:
> I think what he was considering was the question of insisting that
> the VARIADIC keyword be attached to the named argument that actually
> matches the VARIADIC parameter. I think we could do it, but it might
> be a bit of a wart. I notice that
On Wed, 2009-10-07 at 23:32 +0200, Pavel Stehule wrote:
> It's same as my origin ideas, much better formulated. It is ok for me.
You indicated that there may be some implementation difficulty if the
VARIADIC keyword is required for calling using named notation:
http://archives.postgresql.org/pgsq
Jeff Davis writes:
> If we allow calling a variadic function using named notation, the
> VARIADIC keyword is not strictly necessary, but I think we should
> require it. It seems strange without it.
Yeah. My first thought was to just remove the check in
FuncnameGetCandidates, which would have the
On Wed, 2009-10-07 at 16:58 -0400, Tom Lane wrote:
> * completely ignores variadic functions when trying to match
> a call having any named arguments
>
> * does not throw an error for use of the VARIADIC keyword
> in a call together with named arguments
>
> Neither of
2009/10/7 Tom Lane :
> Pavel Stehule writes:
>>> Sorry, I'm having trouble understanding what you're driving at here.
>>> I think we should just not allow named notation to be combined with
>>> VARIADIC, at least for a first version of this feature, either when
>>> defining a function or when call
Pavel Stehule writes:
>> Sorry, I'm having trouble understanding what you're driving at here.
>> I think we should just not allow named notation to be combined with
>> VARIADIC, at least for a first version of this feature, either when
>> defining a function or when calling one. Â We can consider
On Fri, 2009-10-02 at 16:06 +0200, Pavel Stehule wrote:
> see attachment, please
Thank you, marked as "ready for committer".
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
2009/10/2 Jeff Davis :
> On Thu, 2009-10-01 at 17:56 +1000, Brendan Jurd wrote:
>> I've had a look through the documentation and cleaned up a few things.
>
> Thanks, that is helpful. I have included that along with some other
> comment updates in the attached patch.
>
> Paval,
>
> In ProcedureCreat
On Thu, 2009-10-01 at 17:56 +1000, Brendan Jurd wrote:
> I've had a look through the documentation and cleaned up a few things.
Thanks, that is helpful. I have included that along with some other
comment updates in the attached patch.
Paval,
In ProcedureCreate(), you match the argument names to
2009/10/1 Brendan Jurd :
> 2009/9/30 Pavel Stehule :
>> So I dropped variadic functions from mixed/named notation and little
>> bit modified documentation. Please, can some native English speaker
>> look on documentation?
>>
>
> Hi Pavel,
>
> I've had a look through the documentation and cleaned up
2009/9/30 Pavel Stehule :
> So I dropped variadic functions from mixed/named notation and little
> bit modified documentation. Please, can some native English speaker
> look on documentation?
>
Hi Pavel,
I've had a look through the documentation and cleaned up a few things.
I changed the chapter
On Mon, 2009-09-28 at 19:26 +0200, Pavel Stehule wrote:
> > Also, you should consistently pass NIL when you mean an empty list, but
> > sometimes you pass NULL to FuncnameGetCandidates().
>
> It's bug, where is it?
In regproc.c.
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hacke
2009/9/28 Jeff Davis :
> On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
>> when I though about control, I found so syntax with mandatory VARIADIC
>> is difficult implementable. So probably the most feasible solution for
>> this moment is to discard a variadic functions from set of function
On Mon, 2009-09-28 at 18:23 +0200, Pavel Stehule wrote:
> when I though about control, I found so syntax with mandatory VARIADIC
> is difficult implementable. So probably the most feasible solution for
> this moment is to discard a variadic functions from set of functions
> that are callable with n
2009/9/28 Jeff Davis :
> On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
>> This is maybe too strict. I thing, so safe version is allow variadic
>> packed parameter with VARIADIC keyword as Jeff proposes.
>
> The combination of variadic parameters and named call notation is
> somewhat stran
On Mon, 2009-09-28 at 11:50 +0200, Pavel Stehule wrote:
> This is maybe too strict. I thing, so safe version is allow variadic
> packed parameter with VARIADIC keyword as Jeff proposes.
The combination of variadic parameters and named call notation is
somewhat strange, on second thought. Can you i
> Sorry, I'm having trouble understanding what you're driving at here.
> I think we should just not allow named notation to be combined with
> VARIADIC, at least for a first version of this feature, either when
> defining a function or when calling one. We can consider relaxing
> that restriction
On Sun, Sep 27, 2009 at 1:46 PM, Pavel Stehule wrote:
> 2009/9/27 Robert Haas :
>> On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule
>> wrote:
"However, a named variadic argument can only be called the way shown in
the example above. The VARIADIC keyword must not be specified and a
2009/9/27 Robert Haas :
> On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule
> wrote:
>>> "However, a named variadic argument can only be called the way shown in
>>> the example above. The VARIADIC keyword must not be specified and a
>>> variadic notation of all arguments is not supported. To use va
On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule wrote:
>> "However, a named variadic argument can only be called the way shown in
>> the example above. The VARIADIC keyword must not be specified and a
>> variadic notation of all arguments is not supported. To use variadic
>> argument lists you mus
> "However, a named variadic argument can only be called the way shown in
> the example above. The VARIADIC keyword must not be specified and a
> variadic notation of all arguments is not supported. To use variadic
> argument lists you must use positional notation instead."
>
> What is the intended
On Tue, 2009-09-15 at 10:51 +0200, Pavel Stehule wrote:
> My renonc, please, try new patch. I forgot mark regproc.c file.
I think the documentation around calling functions is disorganized:
Variadic functions, functions with defaults, SRFs, out parameters, and
polymorphism are all explained in 34
On Tue, Sep 15, 2009 at 4:51 AM, Pavel Stehule wrote:
>>
>> Same problem. Build log attached.
>>
>> ...Robert
>>
>
> My renonc, please, try new patch. I forgot mark regproc.c file.
>
> regards
> Pavel Stehule
This one compiles for me.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-ha
>
> Same problem. Build log attached.
>
> ...Robert
>
My renonc, please, try new patch. I forgot mark regproc.c file.
regards
Pavel Stehule
nm.diff.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Hello Robert,
2009/9/14 Robert Haas :
> On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> I reworked patch to respect mentioned issues. - this patch still
>> implement mixed notation - I am thing so this notation is really
>> important. All others I respect. The behave is without change
2009/9/14 Robert Haas :
> On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule
> wrote:
>> I reworked patch to respect mentioned issues. - this patch still
>> implement mixed notation - I am thing so this notation is really
>> important. All others I respect. The behave is without change, fixed
>> some
On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule wrote:
> I reworked patch to respect mentioned issues. - this patch still
> implement mixed notation - I am thing so this notation is really
> important. All others I respect. The behave is without change, fixed
> some bugs, enhanced regress tests.
T
Hello,
I reworked patch to respect mentioned issues. - this patch still
implement mixed notation - I am thing so this notation is really
important. All others I respect. The behave is without change, fixed
some bugs, enhanced regress tests.
Sorry for delay.
Regards
Pavel Stehule
p.s. Bernard, p
2009/8/9 Tom Lane :
> Oh, another thing: the present restriction that all function parameters
> after the first one with a default must also have defaults is based on
> limitations of positional call notation. Does it make sense to relax
> that restriction once we allow named call notation, and if
2009/8/9 Tom Lane :
> I've now read most of this patch, and I think there are some things that
> need rework, and perhaps debate about what we want.
>
> 1. As I already mentioned, I think the mixed-notation business is a bad
> idea. It's unintuitive, it's not especially useful, and it substantiall
On Mon, Aug 10, 2009 at 2:23 AM, Robert Haas wrote:
>
>> 2. It doesn't appear that any attention has been given to what happens
>> if CREATE OR REPLACE FUNCTION is used to change the parameter names of
>> an existing function. Since the post-analysis representation of parameter
>> lists is still e
On Sun, Aug 9, 2009 at 9:36 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane wrote:
>>> I'm going to mark the patch Waiting on Author, since it's not close
>>> to being committable until these issues are resolved.
>
>> Is it realistic to think that this will be
Robert Haas writes:
> On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane wrote:
>> I'm going to mark the patch Waiting on Author, since it's not close
>> to being committable until these issues are resolved.
> Is it realistic to think that this will be finished and committed this week?
I didn't want to pr
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lane wrote:
> I've now read most of this patch, and I think there are some things that
> need rework, and perhaps debate about what we want.
>
> 1. As I already mentioned, I think the mixed-notation business is a bad
> idea. It's unintuitive, it's not especially
On Sun, Aug 9, 2009 at 7:30 PM, Tom Lane wrote:
> 1. As I already mentioned, I think the mixed-notation business is a bad
> idea. It's unintuitive, it's not especially useful, and it substantially
> increases our risk of being semantically incompatible with whatever the
> SQL committee might somed
Oh, another thing: the present restriction that all function parameters
after the first one with a default must also have defaults is based on
limitations of positional call notation. Does it make sense to relax
that restriction once we allow named call notation, and if so what
should we do exactl
I've now read most of this patch, and I think there are some things that
need rework, and perhaps debate about what we want.
1. As I already mentioned, I think the mixed-notation business is a bad
idea. It's unintuitive, it's not especially useful, and it substantially
increases our risk of being
56 matches
Mail list logo
