| From: | Marko Tiikkaja <marko(at)joh(dot)to> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <jim(at)nasby(dot)net> |
| Subject: | Re: plpgsql.warn_shadow |
| Date: | 2014-01-15 12:32:13 |
| Message-ID: | 52D67FCD.1050606@joh.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/15/14 1:23 PM, Florian Pflug wrote:
> The fact that it's named plpgsql.warnings already clearly documents that this only affects plpgsql. But whether a particular warning is emitted during compilation or during execution it largely irrelevant, I think. For example, if we called this compiler_warning, we'd couldn't add a warning which triggers when SELECT .. INTO ingores excessive rows.
There is the fact that something being a "compiler warning" gives you an
idea on its effects on performance. But maybe that would be better
described in the documentation (perhaps even more accurately).
I like the idea of warning about SELECT .. INTO, though, but that one
could have a non-negligible performance penalty during execution.
Regards,
Marko Tiikkaja
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masterprojekt Naumann1 | 2014-01-15 12:35:15 | Re: identify table oid for an AggState during plan tree initialization |
| Previous Message | Amit Kapila | 2014-01-15 12:31:43 | Re: Performance Improvement by reducing WAL for Update Operation |