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
Thank you!
-Steve
On Sep 19, 2009, at 6:55 PM, Tom Lane wrote:
Steve Prentice prent...@cisco.com writes:
This patch changes plpgsql IN parameters so they are mutable.
I've applied this, since the consensus seemed to be in favor of it.
I decided not to update the docs for this change
On Sep 16, 2009, at 6:03 AM, Andrew Dunstan wrote:
Abhijit Menon-Sen wrote:
At 2009-09-16 08:37:40 -0400, and...@dunslane.net wrote:
How does this compare with PLSQL?
I don't remember anything of PL/SQL myself, but Pavel Stehule had
this
to say in response to the original post:
This
On Sep 16, 2009, at 8:49 AM, Merlin Moncure wrote:
On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas robertmh...@gmail.com
wrote:
At worst it's an upward-compatible extension, or am I wrong? If it's
useful, which I think it is, what's the harm?
are we guarding against cases like:
select _foo,
On Sep 16, 2009, at 12:44 PM, Michael Glaesemann wrote:
Certainly. I was doing that to have a simple example; obviously you
wouldn't write a mod funciton, and you wouldn't do it in plpgsql.
There
are other case where the lack of mutability in IN parameters causes
you
to create a
On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
2009/9/14 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
So, I guess I'm sadly left feeling that we should probably reject
this
patch. Anyone want to argue otherwise?
+1. I'm really hoping to get something done
On Aug 6, 2009, at 7:12 PM, Robert Haas wrote:
On Thu, Aug 6, 2009 at 7:10 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready for committer, so we
On Aug 3, 2009, at 1:41 AM, Pavel Stehule wrote:
I should to wait with Steve patch - I would to add main sql parser
into plpgsql - than Steve's patch is unnecessary. But if there will be
some problems, then we can use Steve's patch. It is simple - so there
are not big problems with commit.
I
On Aug 3, 2009, at 9:38 AM, Robert Haas wrote:
I sent several notes adding for all patches to be added to
commitfest.postgresql.org prior to the start of CommitFest; AFAIK,
this one was never added.
Hi Robert,
The patch for plpgsql was added as a comment to Pavel's patch. I added
it as a
Since I didn't get completely shot out of the water and a couple
people seemed to think it was helpful, I'm submitting this patch for
consideration in the next commitfest.
This patch changes plpgsql IN parameters so they are mutable.
Previously, they were being forced constant. This patch
Is there a reason we force plpgsql IN parameters to constant? The
reason I ask is because having them mutable would go a long way in
easing a port from Informix's SPL. For better or worse, we have a fair
amount of code in SPL that does something like:
-- pObjectId is an IN parameter
On Jul 29, 2009, at 5:26 PM, Robert Haas wrote:
Wow. I can imagine about a thousand ways that this could break
existing applications. I would not be prepared to bet a dollar that
anything I've written would survive the impact unscathed.
I have a feeling someone else is going to shoot you out
On Jul 29, 2009, at 5:23 PM, Andrew Dunstan wrote:
First reaction is that it would mean we could never pass them by
reference. I know PLPerl uses in effect pass by copy, but what does
PLPgsql do?
Isn't this effectively what we accomplish with an IN/OUT parameter?
--
Sent via
On Jul 29, 2009, at 4:55 PM, Steve Prentice wrote:
Tom added a comment in 1995
For the record, I meant 2005.
-Steve
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jul 17, 2009, at 11:56 AM, Bernd Helmle wrote:
it seems there's something broken, patch complains about a broken
format. Can you please provide a new diff file?
Sorry about that--probably got messed up as I pasted it into the
message. I've attached the patch this time.
Hello,
This patch is intended to supplement Pavel's patch for named and mixed
notation support in 8.5. This patch makes it so a plpgsql function can
call another function with the same parameter names using the named
parameters notation. Without this patch, the following example will
On May 21, 2009, at 10:52 AM, Tom Lane wrote:
It's probably time to bite the bullet and redo the parser as has been
suggested in the past, ie fix things so that the main parser is used.
Ideally I'd like to switch the name resolution priority to be more
Oracle-like, but even if we don't do that
= is more common than as for sure, but this has been talked about
before starting at about this message:
http://archives.postgresql.org/message-id/14319.1228833...@sss.pgh.pa.us
-Steve
On May 21, 2009, at 11:51 AM, Josh Berkus wrote:
The patch adds the AS keyword to the plpgsql grammar
t := fun1(1 as a); -- syntax error: SELECT fun1(1 as
$1 )
t := fun1(a as a); -- syntax error: SELECT fun1( $1
as $1 )
On May 19, 2009, at 6:42 PM, Merlin Moncure wrote:
you have a name conflict here...is it deliberate? I've learned the
hard way to always, always
On May 20, 2009, at 10:24 AM, Pavel Stehule wrote:
this problem is little bit deeper and is related to plpgsql method for
SQL query processing.
I thing so there are two solutions:
a) use dynamic SQL
b) use double quotes for identifier - identifiers have to be lower
t := fun1(a as a);
I followed the past discussions regarding the syntax for named
parameters and I am currently using Pavel Stehule's patch for named
and mixed notation on top of the 8.4 beta.
It seems the way plpgsql substitutes $1, $2, etc for the parameters is
going to reduce the usefulness of this
21 matches
Mail list logo
