Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 understand the utility, because I occasionally knock against this restriction, but if it's incompatible with PLSQL I think we should think about it more carefully. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 understand well, why this behave is in PL/SQL. It hasn't sense in plpgsql, because OUT and INOUT params has little bit different syntax (calling) and nobody will do similar bugs (perhaps). What is interesting - this behave is in conformity with SQL/PSM, where parameters are mutable too. I am for it. PL/pgSQL doesn't promise compatibility with PL/SQL and this change should to help some beginners (and this limit is artificial and unnecessary). Given the existing OUT/INOUT syntax difference as noted, I don't think the patch represents a significant problem. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 PLSQL? I know in Ada an IN argument is in effect a constant. I understand the utility, because I occasionally knock against this restriction, but if it's incompatible with PLSQL I think we should think about it more carefully. 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? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 do some problems. I thing, so I understand well, why this behave is in PL/SQL. It hasn't sense in plpgsql, because OUT and INOUT params has little bit different syntax (calling) and nobody will do similar bugs (perhaps). What is interesting - this behave is in conformity with SQL/PSM, where parameters are mutable too. I am for it. PL/pgSQL doesn't promise compatibility with PL/SQL and this change should to help some beginners (and this limit is artificial and unnecessary). Given the existing OUT/INOUT syntax difference as noted, I don't think the patch represents a significant problem. 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 inconvenience, that is easily worked around. 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. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 from PL/pgSQL to PL/SQL is going to be a lot more inconvenienced by the OUT parameter stuff. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 inconvenience, that is easily worked around. 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. In this case I have not strong opinion. Similarity with SQL/PSM isn't my main argument. I see, so immutable IN arguments are typical problem for beginners. Internally arguments are not immutable - so mutable arguments should help to people who start with PostgreSQL. But I accept, so this increase difference between plpgsql and pl/sql what is wrong too. Regards Pavel cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 behave is in conflict with PL/SQL, what should do some problems. I thing, so I understand well, why this behave is in PL/SQL. It hasn't sense in plpgsql, because OUT and INOUT params has little bit different syntax (calling) and nobody will do similar bugs (perhaps). What is interesting - this behave is in conformity with SQL/PSM, where parameters are mutable too. I am for it. PL/pgSQL doesn't promise compatibility with PL/SQL and this change should to help some beginners (and this limit is artificial and unnecessary). Given the existing OUT/INOUT syntax difference as noted, I don't think the patch represents a significant problem. 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 inconvenience, that is easily worked around. 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. My motivation for submitting the patch was that it makes porting a huge collection of Informix SPL stored procedures easier. There are so many differences between plpgsql and SPL that you would think this wasn't that big of a deal, however, most of the other issues are easily taken care of with a simple sed script or something slightly more advanced (e.g. dealing with the declare/define block differences). This is one of the few compatibility issues where you really need to review and change lots of code by hand. The patch doesn't break existing code and doesn't make it any harder to port code from PL/SQL and on the flip side, this patch with the named/mixed notation patch from Pavel makes porting from Informix's SPL much easier. Thanks for everyone's consideration. -Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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. 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 understand the utility, because I occasionally knock against this restriction, but if it's incompatible with PLSQL I think we should think about it more carefully. 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 bar; -- adjust_foo is inout ?? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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, adjust_foo(_foo) from bar; -- adjust_foo is inout Two things: 1) the patch only affects IN parameters, 2) the parameter is a local copy and doesn't affect parameters/ variables outside of its scope. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 patch. 1. Compatibility with PL/SQL, especially in the extra features direction, has never been a tremendous priority for us before; 2. We don't particularly care if native plpgsql procedures can be back-ported to PLSQL, and if we did there are much greater compatibility issues than this one; 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 mod ( x int, y int ) RETURNS int LANGUAGE plpgsql AS $f$ DECLARE z INT := x; BEGIN z := x % y; RETURN z; END; $f$ Becomes this: CREATE PROCEDURE mod ( x int, y int ) RETURNS int LANGUAGE plpgsql AS $f$ BEGIN x := x % y; RETURN x; END; $f$ -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 mod ( x int, y int ) RETURNS int LANGUAGE plpgsql AS $f$ DECLARE z INT := x; BEGIN z := x % y; RETURN z; END; $f$ 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; $f$ Michael Glaesemann grzm seespotcode net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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; $f$ 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 variable. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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$ BEGIN RETURN (x % y); END; $f$ 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 variable. 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. Michael Glaesemann grzm seespotcode net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 variable. 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. I can't say I disagree with you from a purist standpoint, but for porting existing code sometimes it's more efficient to port what you have without rewriting it. In some of the code I'm looking at porting, this is a very simple example of a common pattern I'm seeing: create function create_some_object(pobjectid uuid, psomefkobjectid uuid) returns uuid as $$ begin if pobjectid is null then pobjectid := newid() end if if psomefkobjectid is null then select objectid into psomefkobjectid from somefktable where whatever; end if -- create the object return pobjectid end; -Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 pass-by-reference in our non-database code, reusing the IN variable is natural. I know not being able to is a longstanding annoyance for me. And I really don't think it's the place of the PostgreSQL project to try to force what some of us think is good PL coding style on people. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 those of us who do a lot of pass-by-reference in our non-database code, reusing the IN variable is natural. I know not being able to is a longstanding annoyance for me. It's the pass by reference case that would be dangerous, in fact. The fact that in C all function parameters are passed by value (unlike, say, FORTRAN) is what makes it safe to modify them inside the function. Anyway, debates about such thigs tend to get a bit religious. getting more practical, I'm slightly inclined to say Steve Prentice has made a good enough case for doing this. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: make plpgsql IN args mutable (v1) [REVIEW]
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 this is that it will simplify importing not-too-well-written Informix code. That might be sufficient reason, but let's not invent claims about it being a common problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
