> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Tom Lane
> Sent: 26 January 2013 18:16
> Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
>
> "Petr Jelinek" <pjmodos@pjmodos.net> writes:
> > 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).
>
> What exactly do you have in mind there? The way we load extensions, they
> can't (AFAIK) see each other's defined symbols, so you couldn't really
make
> an independent extension that would call functions in plpgsql. This is
not
> really open for debate, either, as changing that would risk creating
symbol
> collisions between modules that never had to worry about polluting global
> namespace before.
I can call functions that are exported by plpgsql.so just fine from
different extension now, I just have to preload the plpgsql.so (via LOAD or
guc) first, so I don't see what is the problem here.
> I would note also that we absolutely, positively do not guarantee not to
> change plpgsql's private data structures in minor releases.
That didn't stop people from from writing plpgsql extensions before, don't
see why it would now, the problem is that they have to use hooks now and
those require the function to be executed, making those plpgsql interfaces
external would help with setting up things so that extension can work with
function without function being executed or duplicating a lot of plpgsql
code. As an example of all of this you can see
https://github.com/okbob/plpgsql_lint which is the original module Pavel
wrote before writing this patch.
The other thing is this is something the patch in current form does anyway
so I don't see the harm.
Regards
Petr