Anonymous code blocks (was: Re: GRANT ON ALL IN schema)
Вложения
В списке pgsql-hackers по дате отправления:
| От | Petr Jelinek |
|---|---|
| Тема | Anonymous code blocks (was: Re: GRANT ON ALL IN schema) |
| Дата | |
| Msg-id | 4A986AA6.7030505@pjmodos.net обсуждение |
| Ответ на | Re: GRANT ON ALL IN schema (Petr Jelinek <pjmodos@pjmodos.net>) |
| Ответы |
Re: Anonymous code blocks (was: Re: GRANT ON ALL IN schema)
Re: Anonymous code blocks |
| Список | pgsql-hackers |
> The question is still valid, though it's better put in your words - do > we want to refactor the existing compiler or write a separate one ? So, for now I went with the path of custom compiler and current executor. I attached current version of the patch. I don't expect this to get committed or anything, but I'd like other eyes to take a look at it. What it does: Adds laninline Oid which points to function handling inline code (aka anonymous code block). Adds DO $$some code$$ [ LANGUAGE lanname ] syntax which sends the source code to that laninline function of the specified language (or language set by default_do_language guc). There is implementation for plpgsql with simpler compiler which still creates function struct for the executor (I believe there is no harm in adjusting executor later, when current one works, just does unnecessary stuff). There is doc and a simple regression test for plpgsql implementation. -- Regards Petr Jelinek (PJMODOS)
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера