> -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@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" <pjmo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
