Re: WIP: pl/pgsql cleanup - Mailing list pgsql-patches

From Neil Conway
Subject Re: WIP: pl/pgsql cleanup
Date
Msg-id 1106196482.22946.248.camel@localhost.localdomain
Whole thread Raw
In response to Re: WIP: pl/pgsql cleanup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: pl/pgsql cleanup
Re: WIP: pl/pgsql cleanup
List 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

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: transformExpr() refactor
Next
From: Zhenbang Wei
Date:
Subject: psql zh_TW translation update for CURRENT