Re: plpgsql.warn_shadow

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <jim(at)nasby(dot)net>
Subject: Re: plpgsql.warn_shadow
Date: 2014-01-17 10:26:25
Message-ID: CAFj8pRBhjjAbmW4FUb4TGV2sp67yh_uFv+adt40g-Z6W-R4tDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 to help me push
plpgsql_check_function to core. It can be a best holder for this and
similar checks.

Regards

Pavel

2014/1/15 Marko Tiikkaja <marko(at)joh(dot)to>

> 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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-01-17 10:45:24 Re: plpgsql.warn_shadow
Previous Message Jov 2014-01-17 09:12:06 improve the help message about psql -F