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-21 04:04:48
Message-ID: 1106280288.22946.274.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Thu, 2005-01-20 at 07:57 -0500, Tom Lane wrote:
> Not sure, but it seems like at least as straightforward a translation
> as the other way.  More to the point, it makes clear the difference
> between what is meant to be a long-lived data structure and what isn't.

The latter point is sound, I think -- making that distinction clear
would be nice.

One problem is that this prevents easily using List in pl_comp.c and
gram.y, which is a shame. One solution would be to switch the
CurrentMemoryContext to the function's memory context, and provide a
macro to allocate short-lived memory that can be thrown away at the end
of do_compile(). Alternatively, we could provide some means to allow the
caller of the List API functions to specify the context in which list.c
allocations should be performed.

> Why not?  You'd need to keep the context-to-use in a static variable,
> but that's no great difficulty considering that plpgsql function
> parsing needn't be re-entrant.

Yeah, that's fair -- there's already a plpgsql_curr_compile variable, so
we needn't even add another.


In response to

pgsql-patches by date

Next:From: Stephen FrostDate: 2005-01-21 05:59:17
Subject: Merge pg_shadow && pg_group -- UNTESTED
Previous:From: Euler Taveira de OliveiraDate: 2005-01-21 03:54:17
Subject: Re: uptime function to postmaster

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