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