Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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.


Attachment: plpgsql_cleanup-12.patch
Description: text/x-patch (76.1 KB)
Attachment: refcursor_demo.sql
Description: text/x-sql (21.5 KB)
Attachment: 80_refcursor_bug-1.patch
Description: text/x-patch (654 bytes)

In response to


pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group