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
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 because the docs
don't currently indicate that an IN parameter is
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
How does this compare with PLSQL? I know in Ada an IN argument is in
effect a constant. I
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 behave is in conflict with PL/SQL, what should do some problems.
I thing, so I
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan and...@dunslane.net wrote:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
Makes sense, applies fine, works fine.
How does this compare with
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 behave is in conflict with PL/SQL, what
Andrew Dunstan wrote:
It probably won't cause any problem with code being migrated from
PLSQL, but it will affect code going the other way. The question is:
do we care about that? I'm prepared to be persuaded that we
shouldn't care, but I'm not quite there yet.
Anybody trying to port code
Andrew Dunstan and...@dunslane.net writes:
It probably won't cause any problem with code being migrated from PLSQL,
but it will affect code going the other way. The question is: do we care
about that? I'm prepared to be persuaded that we shouldn't care, but I'm
not quite there yet.
IIRC
I'm not terribly impressed by either of Pavel's arguments. SQL/PSM is
irrelevant, and the existence of one inconsistency doesn't seems to me to be
a good rationale to create another. If there were a major increase in
utility I would be more willing, but at best this overcomes a minor
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 Wed, Sep 16, 2009 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan and...@dunslane.net wrote:
Abhijit Menon-Sen wrote:
At 2009-07-30 13:37:16 -0700, prent...@cisco.com wrote:
This patch changes plpgsql IN parameters so they are mutable.
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,
IIRC the original complaint was from someone trying to migrate code
from T/SQL or some other not-quite-PLSQL language. Like you, I'm on
the fence about whether to accept this patch, but it does have some
in-migration rationale.
As someone who writes a lot of plpgsql, I'm in favor of the
On Sep 16, 2009, at 13:40 , Josh Berkus wrote:
3. This patch eliminates a common plpgsql beginner error and saves all
of us heavy plpgsql users some typing, especially when the use of a
mutable variable means that we can eliminate the DECLARE section
entirely, as in:
This:
CREATE PROCEDURE
Michael,
This is also currently valid:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
DECLARE
z INT := x % y;
BEGIN
RETURN z;
END; $f$
As is this:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
BEGIN
RETURN (x % y);
END;
On Sep 16, 2009, at 15:17 , Josh Berkus wrote:
Michael,
This is also currently valid:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
DECLARE
z INT := x % y;
BEGIN
RETURN z;
END; $f$
As is this:
CREATE FUNCTION mod (x int, y int)
RETURNS int LANGUAGE plpgsql
AS $f$
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
Michael,
Have an example at hand? I'd argue that in a case of a function of more
complexity from a code clarity standpoint you'd want to assign to a new
variable that describes what the new value reflects.
Depends on what programming language you're used to. For those of us
who do a lot of
Josh Berkus wrote:
Michael,
Have an example at hand? I'd argue that in a case of a function of more
complexity from a code clarity standpoint you'd want to assign to a new
variable that describes what the new value reflects.
Depends on what programming language you're used to. For
Josh Berkus j...@agliodbs.com writes:
3. This patch eliminates a common plpgsql beginner error
With respect, that argument is one hundred percent false. I can think
of maybe two complaints about the behavior that we've heard in the last
ten years.
The only real argument I've heard in favor of
2009/7/30 Steve Prentice prent...@cisco.com:
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,
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
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com wrote:
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
On Thu, Jul 30, 2009 at 05:06:17PM -0400, Robert Haas wrote:
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prenticeprent...@cisco.com wrote:
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
On Thu, 2009-07-30 at 17:40 -0700, David Fetter wrote:
This patch changes plpgsql IN parameters so they are mutable. Previously,
they were being forced constant. This patch modifies the plpgsql.sql
regression test and corresponding .out file. The regression test also
makes
sure the
Jeff Davis wrote:
If mutable IN parameters were allowed, I don't even think it could be
allowable to call them from the SQL level, you could only from another
function.
For instance, what would it mean if you did something like:
SELECT foo(a) FROM mytable;
Where foo() mutated it's IN
On Thu, 2009-07-30 at 21:45 -0400, Andrew Dunstan wrote:
For instance, what would it mean if y
SELECT foo(a) FROM mytable;
Where foo() mutated it's IN argument? Would that really be an UPDATE?
No, surely the mutated value will only be visible within the scope of
the function, i.e. it
28 matches
Mail list logo
