Re: plpgsql_check_function - rebase for 9.3

2013/1/26 Petr Jelinek <pjmodos(at)pjmodos(dot)net>:
>> -----Original Message-----
>> From: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
>> owner(at)postgresql(dot)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(at)pjmodos(dot)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
>