From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Assertions in PL/PgSQL |
Date: | 2013-09-15 04:55:45 |
Message-ID: | CAFj8pRDS2OW94OpuLpYX22DXrckGu7q2D=fpWFUAEg-=wQrgPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/9/15 Marko Tiikkaja <marko(at)joh(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-09-15 05:01:18 | Re: git apply vs patch -p1 |
Previous Message | Peter Eisentraut | 2013-09-15 04:35:21 | Re: [PATCH] Revive line type |