Postgres Pro
Downloads
Home   >   mailing lists

Re: plpgsql.warn_shadow - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql.warn_shadow
Date
Msg-id CAFj8pRBjQi1Xo5ZKTzLGR_TOBVefC-vBRMdXL82uOWTsJqcW4w@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql.warn_shadow  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
Tree view



2014/1/15 Marko Tiikkaja <marko@joh.to>
On 1/15/14 11:33 AM, Pavel Stehule wrote:
2014/1/15 Marko Tiikkaja <marko@joh.to>

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 subjective opinion only (as
not native speaker)

just

plpgsql.compile_warning=warning

or

plpgsql.compile_warning=error

looks little bit obscure (or as contradiction). More - "fatal" is used by
gcc and some compilers as "stop on first error"

I was talking about postgres error levels above.  If we define "fatal" to mean ERROR here, I'm quite certain that will confuse people.  How's:

  plpgsql.compiler_warning_severity = 'error' # disable, warning, error matching PG error severity levels ("disable" disables, obviously)

I don't think it is correct - "warning" is "severity" - it is about handling of warnings. It is little bit fuzzy, and I have no good idea now :(
 
  plpgsql.compiler_warnings = 'list, of, warnings'

is not it useless? I don't think it is generally usable. Now plpgsql compiler doesn't raise any warning and better to raise warnings only when the warning can be really important.

Regards

Pavel
 


Regards,
Marko Tiikkaja

pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: plpgsql.warn_shadow
Next
From: Mel Gorman
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance