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
Thank you!
-Steve
On Sep 19, 2009, at 6:55 PM, Tom Lane wrote:
Steve Prentice 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 because the docs
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 throwaway
On Sep 16, 2009, at 8:49 AM, Merlin Moncure wrote:
On Wed, Sep 16, 2009 at 8:59 AM, Robert Haas
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, adjust_foo(_foo) from ba
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 behav
On Sep 13, 2009, at 10:22 PM, Pavel Stehule wrote:
2009/9/14 Tom Lane :
Robert Haas 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 about the plpgsql
parsing
situation be
On Aug 6, 2009, at 7:12 PM, Robert Haas wrote:
On Thu, Aug 6, 2009 at 7:10 PM, Tom Lane wrote:
Bernd Helmle writes:
Here again a patch version with updated documentation. I will stop
reviewing this patch now and mark this ready for committer, so we
have some
time left to incorporate additi
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 com
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 w
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 m
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 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 pgsql-hackers
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 o
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
I
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.
plpgsql_keyword
"=" 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 gramm
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 it
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
have
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");
plpgs
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, alw
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 feature
21 matches
Mail list logo
