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
don't c
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
> don't currently indicate that an IN parameter is constant and I did
Josh Berkus 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 this is that it w
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
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
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 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$
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
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 mo
> 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 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 Wed, Sep 16, 2009 at 8:59 AM, Robert Haas wrote:
> On Sep 16, 2009, at 8:37 AM, Andrew Dunstan 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 se
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
>>
>
> 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
>
Andrew Dunstan 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 the original compl
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
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 should
On Sep 16, 2009, at 8:37 AM, Andrew Dunstan 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 PLSQL? I know in Ada a
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 un
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 unde
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:
http://www.postgres
2009/7/30 Steve Prentice :
> 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 bein
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 functio
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 argumen
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
On Thu, Jul 30, 2009 at 05:06:17PM -0400, Robert Haas wrote:
> On Thu, Jul 30, 2009 at 4:37 PM, Steve Prentice 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 commitfes
On Thu, Jul 30, 2009 at 4:37 PM, Steve Prentice 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 are mutable.
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
28 matches
Mail list logo
