Re: [HACKERS] plpgsql.warn_shadow

Hi Petr, On 3/18/14, 8:38 PM, I wrote: I did one small change (that I think was agreed anyway) from Marko's original patch in that warnings are only emitted during function creation, no runtime warnings and no warnings for inline (DO) plpgsql code either as I really don't think these optional wa

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 20:52, Marti Raudsepp wrote: > On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote: >> Attached V4 uses "shadowed-variables" instead of "shadow". > > I think that should be "shadowed_variables" for consistency; GUC > values usually have underscores, not dashes. (e.g. > intervalst

Re: [HACKERS] plpgsql.warn_shadow

On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote: > Attached V4 uses "shadowed-variables" instead of "shadow". I think that should be "shadowed_variables" for consistency; GUC values usually have underscores, not dashes. (e.g. intervalstyle=sql_standard, backslash_quote=safe_encoding, synchron

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:49 GMT+01:00 Petr Jelinek : > > On 18/03/14 20:45, Pavel Stehule wrote: > > > > 2014-03-18 20:44 GMT+01:00 Petr Jelinek : > >> >> On 18/03/14 20:36, Pavel Stehule wrote: >> >>> >>> >>> +To aid the user in finding instances of simple but common problems >>> before >>> +the

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:45, Pavel Stehule wrote: 2014-03-18 20:44 GMT+01:00 Petr Jelinek >: On 18/03/14 20:36, Pavel Stehule wrote: +To aid the user in finding instances of simple but common problems before +they cause ha

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:44 GMT+01:00 Petr Jelinek : > > On 18/03/14 20:36, Pavel Stehule wrote: > >> >> >> +To aid the user in finding instances of simple but common problems >> before >> +they cause harm, PL/PgSQL provides a number of >> additional >> +checks. When enabled, depending on the

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:36, Pavel Stehule wrote: +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNING

Re: [HACKERS] plpgsql.warn_shadow

On 3/18/14, 7:56 PM, Petr Jelinek wrote: Ok, so I took the liberty of rewriting the patch so that it uses plpgsql.extra_warnings and plpgsql.extra_errors configuration variables with possible values "none", "all" and "shadow" ("none" being the default). Updated doc and regression tests to reflect

Re: [HACKERS] plpgsql.warn_shadow

Hello Tomorrow I'll do a review fast check +To aid the user in finding instances of simple but common problems before +they cause harm, PL/PgSQL provides a number of additional +checks. When enabled, depending on the configuration, they +can be used to emit either a WARNIN

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 20:15, Pavel Stehule wrote: 2014-03-18 20:14 GMT+01:00 Simon Riggs >: On 18 March 2014 19:04, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-ch

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 20:14 GMT+01:00 Simon Riggs : > On 18 March 2014 19:04, Pavel Stehule wrote: > > > I don't think so only "shadow" is good name for some check. Maybe > > "shadow-variables-check" > > "shadowed-variables" would be a better name. > +1 > > -- > Simon Riggs http://www.

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 19:04, Pavel Stehule wrote: > I don't think so only "shadow" is good name for some check. Maybe > "shadow-variables-check" "shadowed-variables" would be a better name. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 19:56 GMT+01:00 Petr Jelinek : > > On 18/03/14 13:43, Pavel Stehule wrote: > > 2014-03-18 13:23 GMT+01:00 Petr Jelinek > >> >> Agree that compile_errors dos not make sense, additional_errors and >> additional_warnings seems better, maybe plpgsql.extra_warnings and >> plpgsql.extra_err

Re: [HACKERS] plpgsql.warn_shadow

On 18/03/14 13:43, Pavel Stehule wrote: 2014-03-18 13:23 GMT+01:00 Petr Jelinek > Agree that compile_errors dos not make sense, additional_errors and additional_warnings seems better, maybe plpgsql.extra_warnings and plpgsql.extra_errors? extra* sound

Re: [HACKERS] plpgsql.warn_shadow

On 18 March 2014 12:23, Petr Jelinek wrote: > Agree that compile_errors dos not make sense, additional_errors and > additional_warnings seems better, maybe plpgsql.extra_warnings and > plpgsql.extra_errors? That sems better to me also. -- Simon Riggs http://www.2ndQuadrant.c

Re: [HACKERS] plpgsql.warn_shadow

2014-03-18 13:23 GMT+01:00 Petr Jelinek : > > On 14/03/14 13:12, Simon Riggs wrote: > >> On 14 March 2014 11:10, Pavel Stehule wrote: >> >>> >>> >>> 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : >>> >>> On 3/14/14 10:56 AM, Simon Riggs wrote: > The patch looks fine, apart from some non-gu

Re: [HACKERS] plpgsql.warn_shadow

On 14/03/14 13:12, Simon Riggs wrote: On 14 March 2014 11:10, Pavel Stehule wrote: 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : On 3/14/14 10:56 AM, Simon Riggs wrote: The patch looks fine, apart from some non-guideline code formatting issues. I'm not sure what you're referring to. I th

Re: [HACKERS] plpgsql.warn_shadow

2014-03-14 13:12 GMT+01:00 Simon Riggs : > On 14 March 2014 11:10, Pavel Stehule wrote: > > > > > > > > 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : > > > >> On 3/14/14 10:56 AM, Simon Riggs wrote: > >>> > >>> The patch looks fine, apart from some non-guideline code formatting > >>> issues. > >> >

Re: [HACKERS] plpgsql.warn_shadow

On 14 March 2014 11:10, Pavel Stehule wrote: > > > > 2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : > >> On 3/14/14 10:56 AM, Simon Riggs wrote: >>> >>> The patch looks fine, apart from some non-guideline code formatting >>> issues. >> >> >> I'm not sure what you're referring to. I thought it looked

Re: [HACKERS] plpgsql.warn_shadow

2014-03-14 12:02 GMT+01:00 Marko Tiikkaja : > On 3/14/14 10:56 AM, Simon Riggs wrote: > >> The patch looks fine, apart from some non-guideline code formatting >> issues. >> > > I'm not sure what you're referring to. I thought it looked fine. > > > Having looked at gcc and clang, I have a proposa

Re: [HACKERS] plpgsql.warn_shadow

On 3/14/14 10:56 AM, Simon Riggs wrote: The patch looks fine, apart from some non-guideline code formatting issues. I'm not sure what you're referring to. I thought it looked fine. Having looked at gcc and clang, I have a proposal for naming/API We just have two variables plpgsql.compil

Re: [HACKERS] plpgsql.warn_shadow

On 3 February 2014 20:17, Pavel Stehule wrote: > Hello > > I am not happy from "warnings_as_error" > > what about "stop_on_warning" instead? > > second question: should be these errors catchable or uncatchable? > > When I work on large project, where I had to use some error handler of > "EXCEPTION

Re: [HACKERS] plpgsql.warn_shadow

On 03/04/2014 03:40 PM, Joel Jacobson wrote: On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote: Lots of code quite correctly relies on this, including some I have written. I really cannot see when it would be a good coding practise to do so, there must be something I don't understand, I wo

Re: [HACKERS] plpgsql.warn_shadow

On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote: > Lots of code quite correctly relies on this, > including some I have written. I really cannot see when it would be a good coding practise to do so, there must be something I don't understand, I would greatly appreciate if you can give a real

Re: [HACKERS] plpgsql.warn_shadow

On 03/04/2014 11:23 AM, Joel Jacobson wrote: I understand that from a technical perspective, the mandatory BEGIN...END you always need in a PL/pgSQL function, is a new block, and the variables declared are perhaps technically in a new block, at a deeper level than the IN/OUT variables. But I wo

Re: [HACKERS] plpgsql.warn_shadow

On Tue, Mar 4, 2014 at 4:06 PM, Tom Lane wrote: > Joel Jacobson writes: >> On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote: >>> You're reasoning from a false premise: it's *not* necessarily an error. > >> Isn't this almost exactly the same situation as we had in 9.0? >> "PL/pgSQL now throws an e

Re: [HACKERS] plpgsql.warn_shadow

Joel Jacobson writes: > On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote: >> You're reasoning from a false premise: it's *not* necessarily an error. > Isn't this almost exactly the same situation as we had in 9.0? > "PL/pgSQL now throws an error if a variable name conflicts with a > column name u

Re: [HACKERS] plpgsql.warn_shadow

On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote: > You're reasoning from a false premise: it's *not* necessarily an error. When wouldn't it be an error? Can you give a real-life example of when it would be a good idea to use the same name of an input parameter as a declared variable? Isn't this

Re: [HACKERS] plpgsql.warn_shadow

Joel Jacobson writes: > I strongly think it should be made an error, because it is most > certainly an error, and even if it's not, it's at least bad coding > style and the code should be fixed anyway, or if one is lazy, turn > this off in the config file and make it a warning instead. You're rea

Re: [HACKERS] plpgsql.warn_shadow

On Wed, Jan 15, 2014 at 1:34 AM, Marko Tiikkaja wrote: > Hi all! > > It's me again, trying to find a solution to the most common mistakes I make. > This time it's accidental shadowing of variables, especially input > variables. I've wasted several hours banging my head against the wall while > sh

Re: [HACKERS] plpgsql.warn_shadow

On 1/27/14, 12:04 PM, Simon Riggs wrote: Florian's point was well made and we must come up with something that allows warning/errors at compile time and once accepted, nothing at run time. I've been thinking about this, and I'm not sure I like this idea all that much. For compile-time warning

Re: [HACKERS] plpgsql.warn_shadow

Dne 3.2.2014 21:48 "Marko Tiikkaja" napsal(a): > > On 2014-02-03 9:17 PM, Pavel Stehule wrote: >> >> I am not happy from "warnings_as_error" >> >> what about "stop_on_warning" instead? > > > abort_compilation_on_warning? I think if we're not going to make it more clear that warnings are only prom

Re: [HACKERS] plpgsql.warn_shadow

On 2014-02-03 9:17 PM, Pavel Stehule wrote: I am not happy from "warnings_as_error" what about "stop_on_warning" instead? abort_compilation_on_warning? I think if we're not going to make it more clear that warnings are only promoted to errors at CREATE FUNCTION time, we can't do much better

Re: [HACKERS] plpgsql.warn_shadow

Hello I am not happy from "warnings_as_error" what about "stop_on_warning" instead? second question: should be these errors catchable or uncatchable? When I work on large project, where I had to use some error handler of "EXCEPTION WHEN OTHERS" I found very strange and not useful so all syntax

Re: [HACKERS] plpgsql.warn_shadow

Hi everyone, Here's a new version of the patch. Added new tests and docs and changed the GUCs per discussion. plpgsql.warnings_as_errors only affects compilation at CREATE FUNCTION time: =# set plpgsql.warnings to 'all'; SET =#* set plpgsql.warnings_as_errors to true; SET =#* select foof(1);

Re: [HACKERS] plpgsql.warn_shadow

On 27 January 2014 10:40, Marti Raudsepp wrote: > On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs wrote: >> For 9.4, we should cut down the patch so it has >> plpgsql.warnings = none (default) | all | [individual item list] > >> plpgsql.warnings_as_errors = off (default) | on > > I hope I'm not

Re: [HACKERS] plpgsql.warn_shadow

2014-01-27 Marti Raudsepp > On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs > wrote: > > For 9.4, we should cut down the patch so it has > > plpgsql.warnings = none (default) | all | [individual item list] > > > plpgsql.warnings_as_errors = off (default) | on > > I hope I'm not late for the bi

Re: [HACKERS] plpgsql.warn_shadow

On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs wrote: > For 9.4, we should cut down the patch so it has > plpgsql.warnings = none (default) | all | [individual item list] > plpgsql.warnings_as_errors = off (default) | on I hope I'm not late for the bikeshedding :) Why not have 2 similar opti

Re: [HACKERS] plpgsql.warn_shadow

> > Putting this and all future options as keywords seems like a poor > > choice. Indeed, the # syntax proposed isn't even fully described on > > list here, nor are examples given in tests. My feeling is that nobody > > even knows that is being proposed and would likely cause more > > discussion if

Re: [HACKERS] plpgsql.warn_shadow

On 26 January 2014 22:44, Pavel Stehule wrote: > > Dne 26. 1. 2014 23:24 "Simon Riggs" napsal(a): > > >> >> On 26 January 2014 15:53, Pavel Stehule wrote: >> > >> > >> > >> > 2014-01-26 Florian Pflug >> > >> >> On Jan26, 2014, at 10:19 , Simon Riggs wrote: >> >> > Also, having >> >> > plpgsql

Re: [HACKERS] plpgsql.warn_shadow

Dne 26. 1. 2014 23:24 "Simon Riggs" napsal(a): > > On 26 January 2014 15:53, Pavel Stehule wrote: > > > > > > > > 2014-01-26 Florian Pflug > > > >> On Jan26, 2014, at 10:19 , Simon Riggs wrote: > >> > Also, having > >> > plpgsql.warnings_as_errors = off (default) | on > >> > makes sense and sh

Re: [HACKERS] plpgsql.warn_shadow

On 26 January 2014 15:53, Pavel Stehule wrote: > > > > 2014-01-26 Florian Pflug > >> On Jan26, 2014, at 10:19 , Simon Riggs wrote: >> > Also, having >> > plpgsql.warnings_as_errors = off (default) | on >> > makes sense and should be included in 9.4 >> >> I still think this is a bad idea, for th

Re: [HACKERS] plpgsql.warn_shadow

2014-01-26 Florian Pflug > On Jan26, 2014, at 10:19 , Simon Riggs wrote: > > Also, having > > plpgsql.warnings_as_errors = off (default) | on > > makes sense and should be included in 9.4 > > I still think this is a bad idea, for the same reasons I don't like > consistent_into (discussed in a s

Re: [HACKERS] plpgsql.warn_shadow

On Jan26, 2014, at 10:19 , Simon Riggs wrote: > Also, having > plpgsql.warnings_as_errors = off (default) | on > makes sense and should be included in 9.4 I still think this is a bad idea, for the same reasons I don't like consistent_into (discussed in a separate thread). But these objections w

Re: [HACKERS] plpgsql.warn_shadow

On 15 January 2014 00:34, Marko Tiikkaja wrote: > Hi all! > > It's me again, trying to find a solution to the most common mistakes I make. > This time it's accidental shadowing of variables, especially input > variables. I've wasted several hours banging my head against the wall while > shouting

Re: [HACKERS] plpgsql.warn_shadow

On Jan20, 2014, at 14:05 , Marko Tiikkaja wrote: > On 1/20/14 1:55 PM, Robert Haas wrote: >> On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: >>> What's so hard about plpgsql.warnings='all'? Or if the fact that it's a >>> list is your concern, I'm not going to oppose to making it a boolean

Re: [HACKERS] plpgsql.warn_shadow

On 1/20/14 1:55 PM, Robert Haas wrote: On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: What's so hard about plpgsql.warnings='all'? Or if the fact that it's a list is your concern, I'm not going to oppose to making it a boolean. Sure, that'd be fine. What I don't want is to have to s

Re: [HACKERS] plpgsql.warn_shadow

On Mon, Jan 20, 2014 at 7:16 AM, Marko Tiikkaja wrote: > What's so hard about plpgsql.warnings='all'? Or if the fact that it's a > list is your concern, I'm not going to oppose to making it a boolean. Sure, that'd be fine. What I don't want is to have to start each function with: #option warn_

Re: [HACKERS] plpgsql.warn_shadow

On 1/20/14 2:25 AM, Robert Haas wrote: On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja wrote: I see these as being two are different things. There *is* a need for a full-blown static analyzer for PL/PgSQL, but I don't think it needs to be in core. However, there seems to be a number of pitfal

Re: [HACKERS] plpgsql.warn_shadow

On Fri, Jan 17, 2014 at 5:45 AM, Marko Tiikkaja wrote: > On 1/17/14 11:26 AM, Pavel Stehule wrote: >> >> After some thinking I don't think so this design is not good. It changing >> a working with exception (error) levels - and it is not consistent with >> other PostgreSQL parts. >> >> A benefit

Re: [HACKERS] plpgsql.warn_shadow

On 1/17/14 11:26 AM, Pavel Stehule wrote: After some thinking I don't think so this design is not good. It changing a working with exception (error) levels - and it is not consistent with other PostgreSQL parts. A benefit is less than not clean configuration. Better to solve similar issues via

Re: [HACKERS] plpgsql.warn_shadow

Hello After some thinking I don't think so this design is not good. It changing a working with exception (error) levels - and it is not consistent with other PostgreSQL parts. A benefit is less than not clean configuration. Better to solve similar issues via specialized plpgsql extensions or try

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 3:09 PM, Pavel Stehule wrote: You first should to say, what is warning and why it is only warning and not error. Personally, I'm a huge fan of the computer telling me that I might have made a mistake. But on the other hand, I also really hate it when the computer gets in my way wh

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja > On 1/15/14 2:27 PM, Pavel Stehule wrote: > >> 2014/1/15 Marko Tiikkaja >> >>> Yeah, me neither, it's just something that needs to be communicated very >>> clearly. So probably just a list plpgsql.warnings would be the most >>> appropriate then. >>> >>> >> I am think

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 2:27 PM, Pavel Stehule wrote: 2014/1/15 Marko Tiikkaja Yeah, me neither, it's just something that needs to be communicated very clearly. So probably just a list plpgsql.warnings would be the most appropriate then. I am thinking so the name is not good. Changing handling warning

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja > On 1/15/14 2:00 PM, Florian Pflug wrote: > >> On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote: >> >>> On 1/15/14 1:23 PM, Florian Pflug wrote: >>> The fact that it's named plpgsql.warnings already clearly documents that this only affects plpgsql. But whether

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 2:00 PM, Florian Pflug wrote: On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote: On 1/15/14 1:23 PM, Florian Pflug wrote: The fact that it's named plpgsql.warnings already clearly documents that this only affects plpgsql. But whether a particular warning is emitted during compilatio

Re: [HACKERS] plpgsql.warn_shadow

On Jan15, 2014, at 13:32 , Marko Tiikkaja wrote: > On 1/15/14 1:23 PM, Florian Pflug wrote: >> The fact that it's named plpgsql.warnings already clearly documents that >> this only affects plpgsql. But whether a particular warning is emitted >> during compilation or during execution it largely i

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 1:23 PM, Florian Pflug wrote: The fact that it's named plpgsql.warnings already clearly documents that this only affects plpgsql. But whether a particular warning is emitted during compilation or during execution it largely irrelevant, I think. For example, if we called this compile

Re: [HACKERS] plpgsql.warn_shadow

On Jan15, 2014, at 13:08 , Pavel Stehule wrote: > 2014/1/15 Florian Pflug >> On Jan15, 2014, at 11:20 , Pavel Stehule wrote: >> > 2014/1/15 Marko Tiikkaja >> > plpgsql.warnings = 'all' # enable all warnings, defauls to the empty >> > list, i.e. no warnings >> > plpgsql.warnings = 'shadow,

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Florian Pflug > On Jan15, 2014, at 11:20 , Pavel Stehule wrote: > > 2014/1/15 Marko Tiikkaja > > On 1/15/14 7:07 AM, Florian Pflug wrote: > > On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: > > It's me again, trying to find a solution to the most common mistakes I > make. This time

Re: [HACKERS] plpgsql.warn_shadow

On Jan15, 2014, at 11:20 , Pavel Stehule wrote: > 2014/1/15 Marko Tiikkaja > On 1/15/14 7:07 AM, Florian Pflug wrote: > On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: > It's me again, trying to find a solution to the most common mistakes I make. > This time it's accidental shadowing of varia

Re: [HACKERS] plpgsql.warn_shadow

On Jan15, 2014, at 10:08 , Marko Tiikkaja wrote: > On 1/15/14 7:07 AM, Florian Pflug wrote: >> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: >>> It's me again, trying to find a solution to the most common mistakes I >>> make. This time it's accidental shadowing of variables, especially input

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja > On 1/15/14 11:33 AM, Pavel Stehule wrote: > >> 2014/1/15 Marko Tiikkaja >> >> I agree, it's better to include the word "compiler" in the GUC name. But >>> do we really need WARNING, ERROR and FATAL levels though? Would WARNING >>> and ERROR not be enough? >>> >>> >>

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 11:33 AM, Pavel Stehule wrote: 2014/1/15 Marko Tiikkaja I agree, it's better to include the word "compiler" in the GUC name. But do we really need WARNING, ERROR and FATAL levels though? Would WARNING and ERROR not be enough? I am not strong in level names - and it is my subject

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja > On 1/15/14 11:20 AM, Pavel Stehule wrote: > > 2014/1/15 Marko Tiikkaja >> >>> Hmm. How about: >>> >>>plpgsql.warnings = 'all' # enable all warnings, defauls to the empty >>> list, i.e. no warnings >>>plpgsql.warnings = 'shadow, unused' # enable just "shadow"

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 11:20 AM, Pavel Stehule wrote: 2014/1/15 Marko Tiikkaja Hmm. How about: plpgsql.warnings = 'all' # enable all warnings, defauls to the empty list, i.e. no warnings plpgsql.warnings = 'shadow, unused' # enable just "shadow" and "unused" warnings plpgsql.warnings_as_errors =

Re: [HACKERS] plpgsql.warn_shadow

2014/1/15 Marko Tiikkaja > On 1/15/14 7:07 AM, Florian Pflug wrote: > >> On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: >> >>> It's me again, trying to find a solution to the most common mistakes I >>> make. This time it's accidental shadowing of variables, especially input >>> variables. I'

Re: [HACKERS] plpgsql.warn_shadow

On 1/15/14 7:07 AM, Florian Pflug wrote: On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: It's me again, trying to find a solution to the most common mistakes I make. This time it's accidental shadowing of variables, especially input variables. I've wasted several hours banging my head agai

Re: [HACKERS] plpgsql.warn_shadow

On Jan15, 2014, at 01:34 , Marko Tiikkaja wrote: > It's me again, trying to find a solution to the most common mistakes I make. > This time it's accidental shadowing of variables, especially input variables. > I've wasted several hours banging my head against the wall while shouting > "HOW CA

Re: [HACKERS] plpgsql.warn_shadow

On 1/14/14, 6:34 PM, Marko Tiikkaja wrote: Hi all! It's me again, trying to find a solution to the most common mistakes I make. This time it's accidental shadowing of variables, especially input variables. I've wasted several hours banging my head against the wall while shouting "HOW CAN THI

[HACKERS] plpgsql.warn_shadow

Hi all! It's me again, trying to find a solution to the most common mistakes I make. This time it's accidental shadowing of variables, especially input variables. I've wasted several hours banging my head against the wall while shouting "HOW CAN THIS VARIABLE ALWAYS BE NULL?". I can't beli