Re: WIP: pl/pgsql cleanup

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: WIP: pl/pgsql cleanup
Date: 2005-01-20 04:48:02
Message-ID: 1106196482.22946.248.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
plpgsql_cleanup-12.patch text/x-patch 76.1 KB
refcursor_demo.sql text/x-sql 21.5 KB
80_refcursor_bug-1.patch text/x-patch 654 bytes

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Zhenbang Wei 2005-01-20 07:26:53 psql zh_TW translation update for CURRENT
Previous Message Neil Conway 2005-01-19 23:44:41 Re: transformExpr() refactor