Re: Assertions in PL/PgSQL - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Assertions in PL/PgSQL
Date
Msg-id CAFj8pRDS2OW94OpuLpYX22DXrckGu7q2D=fpWFUAEg-=wQrgPw@mail.gmail.com
Whole thread Raw
In response to Re: Assertions in PL/PgSQL  (Marko Tiikkaja <marko@joh.to>)
Responses Re: Assertions in PL/PgSQL
List pgsql-hackers



2013/9/15 Marko Tiikkaja <marko@joh.to>
On 2013-09-15 00:09, Pavel Stehule wrote:
this is a possibility for introduction a new hook and possibility implement
asserions and similar task in generic form (as extension). it can be
assertions, tracing, profiling.

You can already do tracing and profiling in an extension.  I don't see what you would put inside the function body for these two, either.

you cannot mark a tracing points explicitly in current (unsupported now) extensions.

These functions share  same pattern:

CREATE OR REPLACE FUNCTION assert(boolean)
RETURNS void AS $$
IF current_setting('plpgsq.assertions') = 'on' THEN
  IF $1 THEN
    RAISE EXCEPTION 'Assert fails';
  END IF;
END IF;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION trace(text)
RETURNS void AS $$
IF current_setting('plpgsq.trace') = 'on' THEN
    RAISE WARNING 'trace: %', $1; END IF;
END;
$$ LANGUAGE plpgsql;

Depends on usage, these functions will not be extremely slow against to builtin solution - can be faster, if we implement it in C, and little bit faster if we implement it as internal PLpgSQL statement. But if you use a one not simple queries, then overhead is not significant (probably). 

You have to watch some global state variable and then execute (or not) some functionality.

Regards

Pavel

 


Regards,
Marko Tiikkaja

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Revive line type
Next
From: Peter Eisentraut
Date:
Subject: Re: git apply vs patch -p1