Re: 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 when I'm trying to test something quickly and making these mistakes on purpose.  Warnings are really good for that: hard to ignore (YMMV) accidentally, but easy to spot when developing.

As to how we would categorize these checks between warnings and errors..  I can't really answer that.  I'm tempted to say "anything that is an error now is an error, any additional checks we might add are warnings", but that's effectively just freezing the definition at an arbitrary point in time.

And why plpgsql warning processing should be different than general
postgresql processing?

What do you mean?  We're adding extra checks on *top* of the normal "this is clearly an error" conditions.  PostgreSQL in general doesn't really do that.  Consider:

  SELECT * FROM foo WHERE fooid IN (SELECT fooid FROM bar);

where the table "bar" doesn't have a column "fooid".  That's a perfectly valid query, but it almost certainly doesn't do what you would want. Personally I'd like to see a WARNING here normally, but I've eventually learned to live with this caveat.  I'm hoping that in PL/PgSQL we could at least solve some of the most annoying pitfalls.

My objection is against too general option. Every option shoudl to do one
clean thing.

It looks to me like the GUC *is* doing only one thing.  "list of warnings I want to see", or the shorthand "all" for convenience.


Regards,
Marko Tiikkaja