Re: plpgsql_check_function - rebase for 9.3

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: plpgsql_check_function - rebase for 9.3
Дата
Msg-id 20747.1359220578@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: plpgsql_check_function - rebase for 9.3  ("Petr Jelinek" <pjmodos@pjmodos.net>)
Ответы Re: plpgsql_check_function - rebase for 9.3  ("Petr Jelinek" <pjmodos@pjmodos.net>)
Список pgsql-hackers
"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
plpgsqlcode - 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
wouldbe useful by itself even if the checker does not get in 9.3 since it would enable users to write
lints/checkers/analysersfor plpgsql as standalone extensions (for my use case this is actually way more useful than
havingthe 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 would note also that we absolutely, positively do not guarantee not
to change plpgsql's private data structures in minor releases.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal - assign result of query to psql variable