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
19 matches
Mail list logo
