On Thu, Sep 28, 2017 at 1:08 AM, Denisa Cirstescu <
denisa.cirste...@tangoe.com> wrote:
> Hi Tom,
>
> You said that trapping an *arbitrary* exception is a “fairly expensive
> mechanism”.
>
I suppose a better (though maybe not perfectly accurate) wording is that
setting up the pl/pgsql execution l
thout exception handling.
Regards
Pavel
>
>
> Thanks,
>
> Denisa Cîrstescu
>
>
>
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Wednesday, September 27, 2017 9:00 PM
> To: David G. Johnston
> Cc: Denisa Cirstescu ;
> pgsql-g
: Denisa Cirstescu ; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Catching errors inside a LOOP is causing performance
issues
"David G. Johnston"
mailto:david.g.johns...@gmail.com>> writes:
> Not sure how much detail you are looking for but the docs say this:
> &qu
"David G. Johnston" writes:
> Not sure how much detail you are looking for but the docs say this:
> "Tip: A block containing an EXCEPTION clause is significantly more
> expensive to enter and exit than a block without one. Therefore, don't use
> EXCEPTION without need."
> https://www.postgresql.
On Mon, Sep 25, 2017 at 9:13 AM, Denisa Cirstescu <
denisa.cirste...@tangoe.com> wrote:
>
> Can someone please explain to me why this worked?
>
> What happened behind the scenes?
>
> I suspect that when you catch exceptions inside of a LOOP and the code
> ends up generating an exception, Postgres
I am adding an example that is runnable in order to demonstrate my point.
CREATE OR REPLACE FUNCTION initialVersion()
RETURNS VOID AS $$
declare
testDate DATE;
begin
for i in 1..99 loop
begin
select now() into strict testDate where 1=0;
exception when others
then null;
