2010/2/23 Bruce Momjian br...@momjian.us:
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
Pavel Stehule wrote:
2010/2/23 Bruce Momjian br...@momjian.us:
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
On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
Pavel Stehule wrote:
2010/2/23 Bruce Momjian br...@momjian.us:
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
2010/2/24 Jeff Davis pg...@j-davis.com:
On Tue, 2010-02-23 at 09:34 -0500, Bruce Momjian wrote:
Pavel Stehule wrote:
2010/2/23 Bruce Momjian br...@momjian.us:
Can someone work on a patch to implement the document changes suggested
below?
This patch is useless now. There are no
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 file.
On Oct 7, 2009, at 7:41 PM, Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com 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
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
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
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
David E. Wheeler da...@kineticode.com 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
2009/10/8 David E. Wheeler da...@kineticode.com:
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
Pavel Stehule pavel.steh...@gmail.com 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. Â
2009/10/7 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
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 these
Jeff Davis pg...@j-davis.com 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
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:
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
Jeff Davis pg...@j-davis.com 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
2009/10/8 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com 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
2009/10/7 Jeff Davis pg...@j-davis.com:
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
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
On Wed, Oct 7, 2009 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us 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.
Jeff Davis pg...@j-davis.com 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.
[
Pavel Stehule pavel.steh...@gmail.com 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:
2009/10/8 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
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/2 Jeff Davis pg...@j-davis.com:
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
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:
2009/9/30 Pavel Stehule pavel.steh...@gmail.com:
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
2009/10/1 Brendan Jurd dire...@gmail.com:
2009/9/30 Pavel Stehule pavel.steh...@gmail.com:
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
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 at a
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
2009/9/28 Jeff Davis pg...@j-davis.com:
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
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
2009/9/28 Jeff Davis pg...@j-davis.com:
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
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
On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule pavel.steh...@gmail.com 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
2009/9/27 Robert Haas robertmh...@gmail.com:
On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule pavel.steh...@gmail.com
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
On Sun, Sep 27, 2009 at 1:46 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/9/27 Robert Haas robertmh...@gmail.com:
On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
However, a named variadic argument can only be called the way shown in
the example above.
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
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, Sep 15, 2009 at 4:51 AM, Pavel Stehule pavel.steh...@gmail.com 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
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 subscription:
Hello Robert,
2009/9/14 Robert Haas robertmh...@gmail.com:
On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule pavel.steh...@gmail.com
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
On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule pavel.steh...@gmail.com 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,
2009/9/14 Robert Haas robertmh...@gmail.com:
On Mon, Aug 24, 2009 at 3:19 PM, Pavel Stehule pavel.steh...@gmail.com
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
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,
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
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
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
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
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
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
On Sun, Aug 9, 2009 at 7:30 PM, Tom Lanet...@sss.pgh.pa.us 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
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us 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
On Sun, Aug 9, 2009 at 9:36 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Aug 9, 2009 at 2:30 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm going to mark the patch Waiting on Author, since it's not close
to being committable until these issues are
On Mon, Aug 10, 2009 at 2:23 AM, Robert Haasrobertmh...@gmail.com 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
56 matches
Mail list logo
