2013/1/26 Petr Jelinek <pjmo...@pjmodos.net>: >> -----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).
A significant improvement in this are can be placing plpgsql.h to other header files. Now plpgsql extensions have to use private copy of this file - what is really ugly Pavel >> >> 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
