Re: plpgsql_check_function - rebase for 9.3

From: "Petr Jelinek" <pjmodos(at)pjmodos(dot)net>
To: "'Pavel Stehule'" <pavel(dot)stehule(at)gmail(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'PostgreSQL Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql_check_function - rebase for 9.3
Date: 2013-01-26 16:52:31
Message-ID: 000c01cdfbe5$88d07da0$9a7178e0$@pjmodos.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Pavel Stehule
> Sent: 28 November 2012 11:07
> To: Selena Deckelmann
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> Hello
>
> a some updated version
>
> * possibility to raise (and filter) performance warnings - detects IO castings
> * detects assign composite value to scalar variable
>

Hello,

I was wondering if maybe this could be split to 2 separate patches, one would be all the changes to the existing plpgsql code - rename delete_function to plpgsql_delete_function and extern plpgsql_delete_function, copy_plpgsql_datum, plpgsql_estate_setup, plpgsql_destroy_econtext and the other patch would be the actual checker.

Reasoning for this is that the first patch (exporting some of plpgsql internals) should be very safe to commit and would be useful by itself even if the checker does not get in 9.3 since it would enable users to write lints/checkers/analysers for plpgsql as standalone extensions (for my use case this is actually way more useful than having the checker as part of core).

Regards
Petr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-26 16:52:35 Re: Support for REINDEX CONCURRENTLY
Previous Message Phil Sorber 2013-01-26 16:50:59 Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)