| От | Neil Conway |
|---|---|
| Тема | Re: WIP: pl/pgsql cleanup |
| Дата | |
| Msg-id | 1106196482.22946.248.camel@localhost.localdomain обсуждение исходный текст |
| Ответ на | Re: WIP: pl/pgsql cleanup (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: WIP: pl/pgsql cleanup
Re: WIP: pl/pgsql cleanup |
| Список | pgsql-patches |
On Tue, 2005-01-18 at 01:02 -0500, Tom Lane wrote: > I think that the existing parsing code feels free to palloc junk data > that needn't be kept around as part of the finished function definition. > It might be better to keep CurrentMemoryContext pointing at a temp > context, and translate malloc() to MemoryContextAlloc(function_context) > rather than just palloc(). (Of course you could hide this in a macro, > maybe falloc()?) Are there really enough short-lived pallocs that this is worth the trouble? One potential issue is that there are plenty of places where we'd want to falloc(), but don't have the function easily available (e.g. in the parser). Attached is a revised patch (no major changes, just grammar cleanup). While rewriting some cruft in PL/PgSQL's gram.y, I noticed that we will overflow a heap-allocated array if the user specifies more than 1024 parameters to a refcursor (a demonstration .sql file is also attached). I think this is probably worth backpatching to 8.0 (and earlier?) -- I've attached a quick hack of a patch that fixes the issue, although of course the fix for 8.1 is nicer. -Neil
В списке pgsql-patches по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера