Re: plpgsql.warn_shadow

From: Petr Jelinek <petr(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Florian Pflug <fgp(at)phlo(dot)org>, Marti Raudsepp <marti(at)juffo(dot)org>
Subject: Re: plpgsql.warn_shadow
Date: 2014-03-18 18:56:25
Message-ID: 532896D9.9050209@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 18/03/14 13:43, Pavel Stehule wrote:
> 2014-03-18 13:23 GMT+01:00 Petr Jelinek <petr(at)2ndquadrant(dot)com
> <mailto:petr(at)2ndquadrant(dot)com>>
>
>
> Agree that compile_errors dos not make sense, additional_errors
> and additional_warnings seems better, maybe plpgsql.extra_warnings
> and plpgsql.extra_errors?
>
>
> extra* sounds better

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 the code changes, everything
builds and tests pass just fine.

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 warnings/errors
during runtime are a good idea.

Note that the patch does not really handle the list of values as list,
basically "all" and "shadow" are translated to true and proper handling
of this is left to whoever will want to implement additional checks. I
think this approach is fine as I don't see the need to build frameworks
here and it was same in the original patch.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
shadow_v3.patch text/x-patch 11.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-18 18:58:46 Re: Portability issues in shm_mq
Previous Message Alvaro Herrera 2014-03-18 18:55:40 Re: pg_archivecleanup bug